Skip to content
Will Rogers edited this page Apr 5, 2016 · 29 revisions

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.

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.

Test plugins

  • Tests should be in a separate plugin with the name .test appended
  • The test plugin should be a 'fragment' plugin with the plugin under test as the host
  • in pom.xml: <packaging>eclipse-test-plugin</packaging>

Types of Tests

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

http://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html

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.
Clone this wiki locally