/
Testing Guidelines

Testing Guidelines

General

  • Tests should not be public

  • Instance variables should have no modifiers

  • Constants have to be private static final

  • Instead of using ““ for master domains, use constant MASTER_DOMAIN for better readability

  • The test API should only be used for setting up the test case. Tested behavior should be implemented using the API of TASKANA.

    • Example: If creating a Task is the test case, then use

      Task task = taskService.newTask(defaultWorkbasketSummary.getId()); task.setClassificationKey(defaultClassificationSummary.getKey()); task.setPrimaryObjRef(defaultObjectReference); task.setManualPriority(123); Task result = taskService.createTask(task);

      instead of

      Task task = TaskBuilder.newTask() .classificationSummary(defaultClassificationSummary) .workbasketSummary(defaultWorkbasketSummary) .primaryObjRef(defaultObjectReference) .manualPriority(123).buildAndStore(taskService);
  • If possible, getting entities from the database should be avoided by using return values.

    • Example:

      Task task = createDefaultTask().manualPriority(123).buildAndStore(taskService); task.setManualPriority(42); Task result = taskService.updateTask(task);

      instead of

  • If tests throw any exception, they must throw Exception.class only

  • Testclass name pattern:

    • rest: Start with the name of the tested class or description of the tested behavior, end with “IntTest” or “RestDocTest”, e.g. TaskControllerIntTest

    • lib: Start with the name of the tested class or description of the tested behavior, end with “AccTest”, e.g. UpdateTaskAccTest

  • Assertions

    • We are using AssertJ only

    • Concatenate the assertions if possible

    • We are strictly using the AssertJ fluent syntax. This means assertThat(<testObject>).<operation>
      examples:
      BAD: assertThat(string.contains(“foo”)).isTrue();
      GOOD: assertThat(string).contains(“foo”);
      General Rule: Do not use any operation within the assertThat() function. Use existing functions from AssertJ’s assert classes.

    • We want to use extracting instead of explicit extracting for collection-type entities.

      • e.g.

        instead of

  • Exceptions:

    • When checking for exceptions in our tests, we want to use one of the following methods:

      • Building an expected Exception and testing for equality with the thrown exception.

        • e.g.

      • Catching the exception thrown and checking if fields are set correctly through assertions.

        • e.g.

Unit Tests

  • Test name pattern: should_ExpectedBehavior_When_StateUnderTest or should_ExpectedBehavior_For_Situation
    In case it is not possible to name the test with “when” or “for”, it is okay to write should_ExpectedBehaviour. The most important thing is that the name is as understandable as possible.

Rest Tests

  • Url and HttpEntity should be extracted. The variables should be named url and auth:

  • When testing our REST Service, we always use an ObjectMapper instance to convert an Object to a JSON representation. We NEVER create JSON Strings manually.

 

Related content

Backend Coding Guidelines
Backend Coding Guidelines
Read with this
Taskana programming model
Taskana programming model
More like this
JavaDoc Rules
JavaDoc Rules
Read with this
Testing of the JBoss/Wildfly deployment
Testing of the JBoss/Wildfly deployment
More like this
Coding Guidelines
Coding Guidelines
Read with this
Module Overview
Module Overview
More like this