Hei Benjamin, thanks for your work. Its good that someone steps forwards with introducing unit tests (finally). Give us some time to read & check things out.
stefan Am 04.01.12 23:25, schrieb Benjamin Gudehus: > 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
