2012/1/14 Michaël Michaud <michael.mich...@free.fr>
> Hi Benjamin,
>
> I just saw how you organized the test framework, and I have several
> questions before I start using it (I'd like to optimize
> DeleteDuplicateGeometriesPlugIn before 1.5.1 release, which is an
> excellent opportunity to test your Framework) :
>
I had a quick look at this PlugIn. Should work. But the I18N Strings in
the initialize() method should move into fields. Or even better: If you
change the dialog initialization to resemble that in UnionByAttributePlugIn.
I would gladly help with implementing tests for this plugin.
> - did you see there is already a package named jumptest in src ? I did
> not pay attention before, but I think we have to care if we want to keep
> the whole src hierarchy consistent.
>
Yes, I saw jumptest and even ran the tests before and after the update of
the
junit.jar (step-by-Step description was posted in the first testing thread).
> - Do you think existing tests (src/jumptest) could easily be merged (or
> simply gathered) in the same package as yours ?
>
Testing classes should _always_ go into the same packages as the fixture
classes
(classes-under-test) are. For example org/foobar/FooBarPlugIn.java and
org/foobar/FooBarPlugInTest.java.
In my opinion we should leave these tests where they are for now and improve
them
when we have implemented more tests for plugins. I.e. we should implement
the tests
outside-in (the tests describe tests for components woven deep in the
system, I think).
But if somebody is interested he/she can complete the tests and move them
into
the packages where the fixture classes (classes-under-test) are.
> - What is the best place for the test framework. I think I would have
> created the package at a higher level (maybe src/test or src/jumptest as
> the existing one). But if there are argument for org.openjump.test, it
> is also ok.
>
I divide our testing components into two parts:
1. The test framework (or better: the test helper classes) in
org.openjump.test.
2. The individual tests in the same packages as the fixture classes are.
We could rename org.openjump.test to jumptests, but the package (test helper
classes) only consist of a few classes, I don't think that we need a
top-level-package
with just a few classes.
In general a project (with tests) contains two source folders (not
packages):
/src/main and /src/test. In our case we just have just one source folder
(/src) for both
main code and test code (which is ok, too).
> - What is more important is to be able to separate test classes from
> core classes at release time. If we put test classes beside plugins as
> you did for UnionByAttributePlugIn, it will be difficult to separate
> them isn't it ? Would it make sens to just prefix tested class names like
> test/com/(vividsolutions?)/jump/workbench/ui/plugin/ExistingPlugInTest
> test/org/openjump/core/ui/plugin/NewPlugInTest
>
Either we could move all files into a two source folder system (main and
test) or
we could ignore *Test.java files from ant and maven build.
I don't know if it is easy to move all files in /src to /src/main with
subversion
or if we could break something. I would prefer to ignore *Test.java files
from build
for now.
Any opinion ?
>
> Michaël
>
Greetings
Benjamin
------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
