[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: AW: [jwt-dev] Tests and unit testing in JWT ?
|
Hi Marc,
I think it isn't necessary to really simulate a click. The corresponding
changes could be made by "producing" GEF-commands, i.e. requesting them from
the EditingDomain and then executing them on the CommandStack.
Regards,
Chris
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Dutoo
Gesendet: Donnerstag, 8. Mai 2008 17:38
An: Java Workflow Toolbox; Valdes Faura Miguel; 'Pierre Vigneras'
Betreff: Re: AW: AW: [jwt-dev] Tests and unit testing in JWT ?
Hi Christian
Thanks for this valuable input.
We now have the "state of testing" in JWT I guess ^^
Concerning the GEF layer, how would you do it ? You would
programmatically simulate a click and then introspect the model to check
it has been correctly changed, is this it ?
Regards
Marc
Christian Saad a écrit :
> Hi all,
>
> concerning the implementation of automated tests, I can speak only for the
> situation in the JWT workflow editor. As has been already mentioned by
Marc
> and Florian there are currently no tests available. Since a large part of
> the WE consists of the management of the graphical interface, the test
cases
> could - in my opinion - be limited to the actual logical layer, that
carries
> out manipulations on the workflow model, since the user interface is
subject
> to rapid change and the maintenance of tests in this field would require a
> lot of attention. I'd like to share a few thoughts about the situation in
> the different parts of the WE:
>
> The EMF Model
> The transformation of the meta model into java classes and the management
of
> the contents is done by the eclipse modeling framework, so there are
> basically no important test cases present (at least none I can think of at
> the moment).
>
> The GEF Layer
> The meta model is linked with the GEF elements. Since the manipulations of
> the model by GEF is a very complex process that depends heavily on the
> implemented routines, which have to be adapted when altering or adding
> elements to the meta model, this layer is possibly the most interesting
for
> formulating automated tests.
> I'm thinking of test cases which simulate the interaction of a user with
the
> UI elements. Definitely useful in my experience would be complex use cases
> that carry out all available actions in as much different combinations as
> possible, e.g. creating/saving/opening a model file and use
> create/select/copy/delete/paste/redo/undo (GEF) commands on the model
> objects.
>
> The Plugin Interface and Graphical UI
> In my experience, manipulations of the plugin part and the non-GEF part of
> the UI affect mostly isolated parts of the code and can (and have to) be
> debugged during the implementation process.
>
> Best Regards,
> Christian
>
> -----Ursprüngliche Nachricht-----
> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
> Auftrag von Mickael Istria
> Gesendet: Mittwoch, 30. April 2008 17:26
> An: Java Workflow Toolbox
> Betreff: Re: AW: [jwt-dev] Tests and unit testing in JWT ?
>
> Hi all,
>
> Here are some of my thoughts about testing.
>
> JWT does not currently integrate automated tests. That will imply to
> spend some time debugging what we currently have in the future. However,
> it is too late to change it, so that there is no interest in adding
> tests now.
> Alexandre Boutin spoke about a "technical debt". Actually, that means
> that when we write code without tests (even when the code works) we will
> have to spend time debugging later, for example we will modify it. With
> this approach we can consider that JWT has a debt that will have to be
> paid in the future. What we can do now is to prevent this debt from
> become larger and larger. If we let this debt become too large, one day
> we won't be able to pay it (and then the project won't be extensible or
> maintainable any more).
> The strategy with the current debt is to pay it when necessary, that
> means when modifying current code.
>
> This comparison with a debt is interesting. I admit it is very
> "business-oriented", and that it is not perfectly convenient with JWT,
> but I think that what he calls a debt is equivalent to the ability to
> progress in our case.
> Indeed, if the "debt" becomes too big, JWT won't attract other
> committers (because coding in JWT will become a difficult puzzle, and
> will require more time), won't react quickly enough to new use cases,
> and won't go ahead. Tests anticipate this situation.
>
>
> About bugs, we can consider that "1 bug fixed = 1 patch + 1 automated
> test". This could become a convention before closing a bug in the
bugzilla.
>
> About testing the UI... Maybe there is nothing to allow this now. But we
> can still try... ;)
> We can at least write some unit tests with classes that are independent
> from Eclipse runtime. We can also learn how to write mock classes to
> replace Eclipse runtime.
>
>
> I'll try to find some interesting things about continuous integration
> and automated tests in PDE. And I promise my next commit will contain
> some tests!
>
>
> Best Regards,
> Mickael
>
>
> Florian Lautenbacher a écrit :
>
>> Hi Marc,
>>
>> thank you for this post. Yes, you are right - currently there are no
tests
>> for JWT WE (I made a few of them myself, but actually I'm not an expert
in
>> how to write tests, especially for graphical modeling environments such
as
>> GEF). I'll read through the chapter of the Gamma & Beck book and will
have
>>
> a
>
>> look whether we can start implementing some tests without neglecting the
>> next features and fixing bugs...
>> Any assistance here is of course always welcome :-)
>>
>> I agree with you (and Alexandre Boutin) that at least every time
something
>> has been broken, one should add some tests after fixing it in order to
>>
> make
>
>> sure it won't break again.
>>
>> Best regards,
>>
>> Florian
>>
>> -----Ursprüngliche Nachricht-----
>> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
>> Auftrag von Marc Dutoo
>> Gesendet: 30 April 2008 15:31
>> An: Java Workflow Toolbox
>> Betreff: [jwt-dev] Tests and unit testing in JWT ?
>>
>> Hi all
>>
>> The issue of tests and how to do unit testing in JWT is of interest for
>>
> the
>
>> core development team as well as anybody wishing to use JWT for his own
>> purpose.
>>
>> So what do you think about tests and unit testing in JWT ?
>>
>> As a starter, I've tried to compile a few answers here - feedback welcome
>>
> !
>
>> JWT tests status :
>> * none in WE, many but not yet automated in Transformations, junit
>>
> tests
>
>> in runtime parts (but their impl is generally not jwt per se since not
>> available on eclipse because of license issues)
>>
>> Unit testing
>> * for unit tests of eclipse plugins, use pde.junit plugin (from jdt ui
>> page). In addition to executing junit tests, it takes care of
initializing
>> an eclipse workspace, as required by eclipse plugins.
>> * "httpunit-like" tools are scarce and far from useful in the field of
>> heavy client UIs. Some of my colleagues had a little bit of experience
>>
> with
>
>> such IBM tools targeting Swing UIs back then, and say that writing tests
>>
> was
>
>> far more cumbersome and long than writing the UI itself -_-
>> * hence nothing car replace functional testing (test plans etc.) to
>>
> know
>
>> a UI is not broken in use or impl - though a good architecture (like emf
-
>> gmf - extension points - common patterns etc.), development and
>>
> integration
>
>> methodology, limits risks.
>> * more about testing eclipse plugins : see the excellent gamma & beck
>> book, and especially its chap12 that is freely available here
>> http://today.java.net/today/2004/02/02/ch12Eclipse.pdf
>>
>> So what if you want to make your own tooling by extending JWT, and you'd
>> like to have some level of trust in the fact that a given release of JWT
>>
> is
>
>> not broken, or that your extensions are not breaking it ? According to
>> Alexandre Boutin (main french advocate of Lean Programming),
>> * it would not be business-savvy to spend time writing tests for
>>
> existing
>
>> code. If code exists without tests and you trust it, use it so.
>> * But if it breaks at some point, then add tests ensuring it won't
>>
> break
>
>> the same way anymore.
>>
>> Regards,
>> Marc
>> _______________________________________________
>> jwt-dev mailing list
>> jwt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jwt-dev
>>
>> _______________________________________________
>> jwt-dev mailing list
>> jwt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jwt-dev
>>
>>
>
> _______________________________________________
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jwt-dev
>
>
>
> _______________________________________________
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jwt-dev
>
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
