-
Notifications
You must be signed in to change notification settings - Fork 97
UnitTests
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.
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.
- 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>
Technically, there are different types of tests which we identify by their file names:
- Plain JUnit tests:
*[[Test]].java
http://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html - JUnit Plug-in tests that need the Eclipse runtime but no GUI:
*[[IT]].java
https://maven.apache.org/surefire/maven-failsafe-plugin/examples/inclusion-exclusion.html - JUnit Plug-in tests that need the runtime and the GUI or A demo that requires user input or other interaction. Not a real test, but happens to be implemented with JUnit:
*Demo.java
http://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html
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.