@Stephan
Yes, and there is much work to be done :)
I'll document that code that we already have. To make it more easier to
start with unit testing.
@Michael
Yes, I think the new testing environment and the upcoming refactorings
should go into a svn branch.
Scripting/macros: That's how I developed all of my plugins; there is no
need to show a dialog.
2012/1/5 Michaël Michaud <michael.mich...@free.fr>
> 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>:
> > 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
> listJump-pilot-devel@lists.sourceforge.nethttps://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
>
>
------------------------------------------------------------------------------
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
