@@ -411,3 +411,34 @@ Some resources for these annotations are:
411
411
* http://minds.coremedia.com/2012/10/31/jsr-305-nonnull-and-guava-preconditions/
412
412
* http://findbugs.sourceforge.net/manual/annotations.html (the package names are outof date
413
413
and should be java.annotation instead of edu.umd.cs.findbugs.annotation but the descriptions are accurate)
414
+
415
+ # Testing
416
+
417
+ With regards to testing Geonetwork is a standard Java project and primarily depends on JUnit for testing. However there is a very important
418
+ issue to consider when writing JUnit tests in Geonetwork and that is the separation between unit tests and integration tests
419
+
420
+ * * Unit Tests* - In Geonetwork unit tests should be very very quick to execute and not start up any subsystems of the application in order to keep
421
+ the execution time of the unit tests very short. Integration tests do not require super classes and any assistance methods can be static
422
+ imports, for example statically importing org.junit.Assert or org.junit.Assume or org.fao.geonet.Assert.
423
+ * * Integration Tests* - Integration Test typically start much or all of Geonetwork as part of the test and will take longer to run than
424
+ a unit test. However, even though the tests take longer they should still be implemented in such a way to be as efficient as possible.
425
+ Starting Geonetwork in a way that isolates each integration test from each other integration test is non-trivial. Because of this
426
+ there are ` abstract ` super classes to assist with this. Many modules have module specific Abstract classes. For example at the time
427
+ that this is being written ` domain ` , ` core ` , ` harvesters ` and ` services ` modules all have module specific super classes that need to
428
+ be used. (` harvesting ` has 2 superclasses depending on what is to be tested.)
429
+ The easiest way to learn how to implement an integration test is to search for other integration tests in the same module as the class
430
+ you want to test. The following list provides a few tips:
431
+ * * IMPORTANT* : All Integrations tests * must* end in IntegrationTest. The build system assumes all tests ending in IntegrationTest is
432
+ an integration test and runs them in a build phase after unit tests. All other tests are assumed to be unit tests.
433
+ * Prefer unit tests over Integration Tests because they are faster.
434
+ * Search the current module for IntegrationTest to find tests to model your integration test against
435
+ * This you might want integration tests for are:
436
+ * Services: If the service already exists and you quick need to write a test to debug/fix its behaviour.
437
+ If you are writing a new service it is better to use Mockito to mock the dependencies of the service so the test is
438
+ a unit test.
439
+ * Harvesters
440
+ * A behaviour that crosses much of the full system
441
+
442
+ * org.fao.geonet.utils.GeonetHttpRequestFactory* : When making Http requests you should use org.fao.geonet.utils.GeonetHttpRequestFactory instead
443
+ of directly using HttpClient. This is because there are mock instances of org.fao.geonet.utils.GeonetHttpRequestFactory that can
444
+ be used to mock responses when performing tests.
0 commit comments