Sorry, the last post became badly formatted, so I post it again. Hope this
looks better.
Here is an update:
I've finished point 2. Now it's possible to run unittests for the
UnionByAttributePlugIn.
Project page: https://github.com/hastebrot/openjump-tools-sandbox
Zip file: https://github.com/hastebrot/openjump-tools-sandbox/zipball/master
Please grab the zip file and try it out. I've included all openjump libraries
and added junit4 in the lib directory, so everyone has nothing to do but
import the project into eclipse.
You may start with executing the junit tests in
src/org/openjump/tools/tests/TestToolsTest.java.
I'm happy about any suggestion and feedback. You'll see that the tests
work, but that there are some refactorings needed on the OpenJump source
code. You'll also see that I've tried to write it BDD style
(given-when-then).
This is just a sandbox for concepts. Eventually I will copy the sources
into openjump's subversion repository, when everything went fine.
Here is what I have to write about (C) formulate a guideline to refactor
existing legacy plugins:
1. Create an empty Java.project for experiments
2. Copy jar depenndecies to lib
3. Copy single PlugIn source to src (downside: out of main repository version
control)
4. Try to run plugin
5. Refactor PlugIn (maybe) to execute simple test with a shapefile fixture
(chance no behaviour)
6. Write Tests for bounded context and edge cases
7. Refactor mercilessly
See also: Manuel Küblböck: “How to make changes to rotten legacy code”,
http://qualityswdev.com/2011/02/09/how-to-make-changes-to-rotten-legacy-code/
So we are now at point 6. I've changed nothing in UnionByAttributePlugIn.
Next thing is to write all tests / interactions for it.
--Benjamin
2012/1/4 Benjamin Gudehus <hasteb...@googlemail.com>:
> Here is an update:
> I've finished point 2. Now it's possible to run unittests for
> theUnionByAttributePlugIn.
> Project page: https://github.com/hastebrot/openjump-tools-sandboxZip
> file: https://github.com/hastebrot/openjump-tools-sandbox/zipball/master
> Please grab the zip file and try it out. I've included all
> openjumplibraries and added junit4 in the lib directory, so everyone
> hasnothing to do but import the project into eclipse.
> You may start with executing the junit tests
> insrc/org/openjump/tools/tests/TestToolsTest.java. I'm happy about
> anysuggestion and feedback. You'll see that the tests work, but
> thatthere are some refactorings needed on the OpenJump source code.
> You'llalso see that I've tried to write it BDD style
> (given-when-then).
> This is just a sandbox for concepts. Eventually I will copy thesources
> into openjump's subversion repository, when everything wentfine.
> Here is what I have to write about (C) formulate a guideline
> torefactor existing legacy plugins:
> 1. Create an empty Java.project for experiments2. Copy jar
> depenndecies to lib3. Copy single PlugIn source to src (downside: out
> of main repositoryversion control)4. Try to run plugin5. Refactor
> PlugIn (maybe) to execute simple test with a shapefilefixture (chance
> no behaviour)6. Write Tests for bounded context and edge cases7.
> Refactor mercilessly
> So we are now at point 6. I've changed nothing
> inUnionByAttributePlugIn. Next thing is towrite all tests /
> interactions for it.
> --Benjamin
> 2012/1/4 Benjamin Gudehus <hasteb...@googlemail.com>:
>> 2. Legacy code and testing
>>
>> How to test plugins (from the tools menu)?
>>
>> (1) Create and setup a JUMPWorkbench with WorkbenchFrame and
>> WorkbenchContext. The method JUMPWorkbench.main() has all needed
>> instructions. In order to run the plugins we need to set
>> WorkbenchFrame visible. This is only required because
>> WorkbenchFrame.position() wants to relocate internal frames, but
>> shouldn't be a requirement. However to show the WorkbenchFrame could
>> be helpful when developing test cases.
>>
>> (2) Initialize and call (execute and/or run) PlugIns. The method
>> AbstractPlugIn.toActionListener() has all needed instructions. We need
>> to wait until the plugin finished until assertions can be made. We
>> should test plugins with different dialog values handled to the plugin
>> and all private methods directly.
>>
>> I finished point (1) and am working in point (2). After that I will
>> but some source code online, so everyone can experiment a bit with
>> tests.
>>
>> -----
>>
>> Now let's look at (A) the structure of the source code of an example
>> plugin and then (B) formulate the layout of a test class. After that
>> we can (C) formulate a guideline to refactor existing legacy plugins.
>>
>> Concerning (A): I'll use UnionByAttributePlugIn (sourcecode: [1]) as a
>> showcase and later as a object-under-test. Michaël recently made some
>> nice refactorings (sourcecode: [2]) on this plugin that also improved
>> cohesion on the source code. I think [1] has the following structure:
>>
>> [1] https://gist.github.com/1554708#file_union_by_attribute_plug_in.java
>> [2]
https://gist.github.com/1554708#file_union_by_attribute_plug_in.r2519.java
>>
>> 1. PlugIn installation (JUMPWorkbench/Setup)
>> - Constructor (empty)
>> public UnionByAttributePlugIn() {}
>> - Method: initialize() / FeatureInstaller
>> 2. Input dialog (PlugIn.execute())
>> - Fields: Translation Strings
>> private final static String LAYER = I18N.get("...PlugIn.layer");
>> - Field: Dialog
>> private MultiInputDialog dialog;
>> - Method: initDialog()
>> - Method: execute() to initialize and show the dialog
>> 3. Execution/Result/Report (Ok button)
>> - Method: run() to run the tool asynchronously
>> privateMethods
>>
>> It consists of three parts. 1. provides an initialize() method for
>> JUMPWorkbench/Setup which installs a menu entry. 2. provides a multi
>> input dialog which provides a key store with different values (I
>> really like this key/value concept). The dialog is shown to the user
>> with execute(). 3. is the run() method which creates a result layer
>> and makes use of private methods.
>>
>> We should refactor the plugins later, so calling them is possible in
>> two different ways. Firstly by showing the user a multi input dialog
>> and secondly by provide key-values directly to the plugins. The
>> changes by Michaël in [2] resemble exactly what I'm thinking of: He
>> introduced some field to the plugin class analogue to the fields in
>> the dialog. For now I'll try to subclass MultiInputDialog for tests to
>> provide custom values to the plugin, without setting the dialog
>> visible. Then I'll set it as the private field dialog.
>>
>> Concerning (B): Layout of a test class
>>
>> @BeforeClass: Create a WorkbenchFrame (and optionally set it visible).
>> @Before: Create a new TaskFrame.
>> @Test: Multible test cases.
>> - Load a Shapefile.
>> - Call the PlugIn with arguments.
>> - do assertions
>> @After: Close all internal frames (projects)
>> @AfterClass: Close the WorkbenchFrame
>>
>> For all tests cases (@Tests) we need a single
>> WorkbenchFrame/WorkbenchContext which is initialized in @BeforeClass.
>> A single test case loads a shapefile and calls the plugin with
>> arguments (my custom MultiInputDialog). Then multiple assertions
>> follow. After that we will close all internal frames in @After.
>>
>> I'll write about (C) later.
>>
>> --Benjamin
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
