Testing jcp

We use visual GUI testing for quality assurance of the JCP applet (this could also be introduced for the application, but since they share the code we do it for the applet only right now. This uses Fest and JUnit. Test are found in src/test. Running AllJCPTests as JUnit test runs all tests. You should always run these before and after you test.

For new functionality, tests should be added. Have a look at the code to see how this is done. In general, you need to simulate the user actions via FEST and then test if appropriate changes on the model took place. Note that currently test do not do a visual check, but check the model. In most cases this should be sufficient and visual checks are difficult. Comment by rwst: One might argue that using FEST against model bugs is overkill and changing the GUI will break model tests. In an ideal world, we would bypass the GUI but that would need a tailormade solution.

Further discussion of the tests written in 2009/10

If you have the JCP source installed as an Eclipse project, you can even run individual tests and parts of them by right-clicking on the resp. class or method in the project view, then Run as/JUnit test. Test classes can be found under src/test/org.openscience.jchempaint. These classes, as implemented around 2009/10 suffer from two problems: they lump many individual tests together in four classes, and often they use GUI testing methods (FEST) where there should be no reference to how an action was achieved (e.g. menu or button). The result of that is tests failing because of side effects from previous tests because the applet wasn't restarted (example JCPEditorAppletBugsTest.testBug65()) and tests failing because the GUI has changed in a normal way but the test depended on it being fixed. The first can be improved by separating all individual tests into single instances of AbstractAppletTest.