Hi Benjamin,
It will take me some times to read carefully your proposals and test
your contributions.
I see many good ideas.
We have just to be careful because we are a small team with limited
experience, and OJ is quite a big project with a long history and much
legacy code hosted by the project or by other projects.
That said, I don't know how much you can contribute, and what's your
vision for OJ.
If you have time for important contributions, maybe it's worthwhile
creating a branch in the svn, to be able to test more innovative changes
while keeping and updating a stable release.
Let's see what Stefan and Ede say.
Michaël
PS : Having a very quick look at your examples, I thought that the
required refactoring could help making plugins scriptables (currently,
it's quite difficult to use plugins from beanshell), and maybe later to
implement a macro recorder (though, I may have extrapolated a bit too
far ;o)).
Le 04/01/2012 23:25, Benjamin Gudehus a écrit :
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
<mailto: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
<mailto: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
------------------------------------------------------------------------------
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
