I had a closer look at the plugin, there is no need to change initialize()
in order to run tests. The needed fields are already there:
private Layer itemlayer = null;
private boolean deleteOnlyForSameAttributes = false;
--Benjamin
2012/1/14 Benjamin Gudehus <hasteb...@googlemail.com>
> 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
