UnitTests

Unit Tests

(XXX macro: "PageOutline")

---

The following is currently under discussion. It's not finalized.

Please add comments for improvements and more elegant solutions on anything and try to run the configurations. Lots of tests cannot be properly loaded, or be initialized, they might run forever, or freeze the test process completely. Certainly many tests fail due to site specific settings. And of course many tests just fail.

Our first task is to get the tests running for all sites, or, as second and worse choice, identifying which of them shall be disabled for a specific site and how to do so automatically.

General

Ideally, CSS code is developed in a test-driven manner. Writing the test first has many advantages:

• Helps to brainstorm what the code should do
• Almost automatically breaks the code into testable and thus modular sections
• Test code serves as a how-to-use documentation for other developers
• Test code serves as a specification, in principle allowing anybody to perform the implementation
• When the test passes, you know at least something "works" as intended

Last not least, you can use the test later to assert that existing functionality is still available. Tests can even be executed as part of an integration build.

Types of Tests

Technically, there are different types of tests which we identify by their file names:

• Plain JUnit tests: *[[UnitTest]].java
• JUnit Plug-in tests that need the Eclipse runtime but no GUI: *[[HeadlessTest]].java
• JUnit Plug-in tests that need the runtime and the GUI: *[[UiPluginTest]].java
• A demo that requires user input or other interaction. Not a real test, but happens to be implemented with JUnit: *Demo.java

Test Guidelines

All developers should import all available plugins into their development environment. The reason is that missing a bundle means missing the tests for this bundle and potentially modifying another bundle that is a prerequisite for the missing one such that this bundle is corrupted (tests would fail but they are not executed).

Tests should have the following features:

• Automatically executable AND terminating without any user interaction or user supervision.
• Not taking an exceptional long time, if it is not necessary for the test itself.
  • E.g. check for database connections in the test setup once. Do not wait for connection timeout for any test to figure out that the test eventually fails.
  • Do not use excessive logging (there's no need if no one's watching), concentrate on important test debug info.
• Use a Logger, not the standard console, if possible.

Once a properly functioning test environment has been established, the hg push procedure should look like follows:

• pulling the latest snapshot from the sourceforge repo
• locking the repo that nobody else may push in between corrupting your current snapshot
• merging your changesets with the latest snapshot
• run all tests of all bundles
  • green - pushing your changesets and unlocking the repo
  • red - unlocking the repo and start debugging the failing tests

Whether such an ideal pushing routine is possible with our number of developers has yet to be found out - push wars might probably occur as the tests run for quite a while.

Possible ways to easen the trouble of push/commit wars are 'push queues' in which you reserve your place to commit and wait for your turn (or negotiate your place in the queue with somebody else). Or having a DVS after all, any site or group collects their changesets locally before the push, reducing the number of pushes to the sourceforge repo.