Tests

Launching all tests

Tests are launched with each gradle build, which may be comprised in a gradle run if the first.
However, they can also be launched with

gradle test  
firefox build/reports/tests/index.html  

Launching the tests of one module

For instance, in order to launch the tests of the crypt module only

gradle test --tests crypt*

Conventions for test files

Tests files locations follow the gradle convention: e.g. src/test/java/crypt/impl contains the tests for the implementation files of the crypt module.

Tests files names follow the convention XTest, where X is the name of the class being tested.

Tests files contents follow the JUnit convention.

package crypt.impl; //locate yourself in same package as class being tested

import static org.junit.Assert.*; //JUnit
import org.junit.Test;

import ...; //other dependencies 

public class XTest {
	private static final String plainText = "tatata";

	@Test   //annotate this as a test
	public void test() { //name of method does not matter, often that of the method being tested
		...
		assertTrue(...);
	}
}

Notes on persistence.

The tests done on the model.syncManager package check that the Java Persitence API (JPA) is correctly implemented. All test instances are using a different EclipseLink database (all declared with a different random name). All SyncManagers tested (item, user and message) use the JPA formalism to put or remove objects to and from the database (see Model section).

Those tests pass. Nevertheless, according to the persistence delay, some objects can be seen as part of a database that is not the one they belong to.

To highlight this phenomena, comment all the controller.ControllerTest.testL() then launch the ./gradlew test command. The model.syncManager.UserSyncManagerImplTest.testC() should failed.

Actually, one User instance is created and committed in the database in the ControllerTest (that is obviously not deleted by the testL() method anymore) and it is seen during the execution of UserSyncManagerImplTest.testC(), making it fail. Notice that this User object can not be in the database created by the ControllerTest as this database is delete by the execution of ControllerTest.deleteBaseAndPeer() method at the end of the test case. That means that this "object overlapping" is a side effect of the persistence.

This phenomena is not a problem at runtime because we only use one database.

Notes on network tests.

Due to the fact that no two peers can be launched at the same time on the same server, no network test has been done. To workaround this problem, one should probably use either a server with a fix IP somewhere or a docker container that could launch others peers during tests.