REST-assured

In the repository we use a library called REST Assured that can help you with this. It is a Java library that provides a domain-specific language (DSL) for writing powerful, maintainable tests specifically for REST APIs. The syntax uses 'given-when-then' to describe the test steps - which is very similar, but a bit more explicit compared 'arrange-act-assert' in unit testing and makes it easy to read.

link to official documentation: https://rest-assured.io/

Test containers

Since we need to test the whole system, we need to have a database running. We could use a real database, but that would make our tests slow and dependent on the database. Instead, we can use a library called Testcontainers that can start a real database in a docker container for us. This way we can have a real database running, but it is isolated and we can control it from our tests.

Hint: you can also add a initialize the database container with a script, so you don’t start with an empty database.

link to official documentation: https://java.testcontainers.org/

Design and end-to-end testing

End-to-end tests tend to be slow, hard to maintain, can be flaky and give less precise errors. Therefore, it is important to have many isolated tests, to catch the bugs early and to make sure that the different parts of the system work as expected.

Isolated tests, have the advantage (besides being more scalable), that they put pressure on the design of your application: In order to test a class in isolation, you need to make sure that the class is loosely coupled with other classes. This is a good thing, because it makes your code more modular and easier to maintain.

So, by TDD-ing, we don’t only get feedback on the behavior of the code, but also of the design of the code - You could say "if its hard to test, we didn’t build it right".

If you’re interested, an interesting resource on how the way you test impacts your design (and vice versa): https://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam or https://www.youtube.com/watch?v=fhFa4tkFUFw&t=13s by J.B. Rainsberger

Writing test-able code

One first easy setup is to use package private visibility more often. It is actually the default in java, and with reason. When you then put your unit test in the same package (but it its own source tree), you can have the test class look at or use the package private members of the class in its assertion or verification very easily. Keep in mind the test should be coupled to the behavior of the class, but as little as possible to its implementation details.

Test-ability is also improved by using the design rule program against interfaces, not concrete classes.
If you do that in your design, you can very easily make specialized implementations of those interface methods that you need in your test, to provide those specific values or reactions that you need in your test, without having to jump through a lot of hoops to get the test set up.
This easy setup is where Mockito comes in.

It is not the business' business to worry about:
persistence
where service come from or who implements them.

By injecting or otherwise providing the business with the services it needs makes the business code testable without making it dependent or even know the actual implementing classes. And that is really all that counts. The business code makes the application valuable, the rest is either plumbing or already available code.[1].

Instead hand the service or resource to the business, or give it some provider of a resource.

Business class fit for testing

We’ll further explain this concept in class and in the context of PRJ2. There are quite some design ideas behind it, so don’t worry if you don’t understanding it immediately.

Let us look at an example as a class diagram.

In the picture above you see a class diagram which shows a detail in which a business class 'lives' in an environment that is designed to make sure the business class sticks to its business:

Dealing with business entities such as customers and products.
Uses services to do the business' bidding, such as saving stuff to a database, provided as a service to the business class.
And the business code NOT responsible for how to show things in a UI.

In the above example we provide a factory or provider of the services that the business code requires.

The business class appears in two worlds:

Before the business class can used in real life, it has to be trained and tested. Feels a bit like a student right?

You should note the arrows in the diagram. They provide direction and make it the diagram a directed graph, and lets a dependent point to a depends-on, like the BusinessClass depends on a Service, which is an abstract class or better still, an interface. Also note that the service does not point to, or is dependent on the business, which is good, because it makes the service reusable in other contexts.
The service implementing classes are dependent on the Service definition which is shown with the "implements arrow", pointing from sub to super type.

In the business school, there is a test class, that creates instances of the business class and hands it implementations of the services the business needs, but does that by giving it a specialized service factory that produces mock service implementations. The business class is NOT aware of that. It uses the service in the way it is programmed, which allows the test class to verify that that programming is correct. The test class is in complete control and can also give the business class situations that are extensions to the normal happy path to ensure that those situations are also handled properly. If that sounds like an exam setting at school, you would be right.

You can tell these worlds in the class diagrams apart by the fact that one has a pink BusinessTest class with test methods.

In the 'normal' non-testing Application world, the design has taken some provisions to make sure the business class can work in both worlds. To provide the business class with a factory from which it can obtain Service implementations, a so called Assembler is added. This Assembler, in the figure at the top of the application class diagram, typically creates or instantiates the business class and provides it with all it needs, in this case an implementation of a ServiceFactory. Note that the assembler in this case also creates the UI part. In desktop applications this is the responsibility of the Main class of the application.

This approach of providing an instance of some class implementing an interface or realizing an abstract class to a business class that needs it is called dependency injection.

Dependency injection is providing the services required by some class by means of constructor parameters, setters or otherwise, to avoid that the dependencies of the class are created by that class itself.

Stay cool, have a Mockito.

You are not the first developer in this situation, so someone has automated the creation of 'fake' objects or mocks for us:
Mockito is a framework that can create various objects that are useful for testing.

Mock is an object that behave like a (alternate) implementation of a class or interface. This is akin to an actor (or actress) or stunt-double that behaves exactly like you tell it to. A mock also saves any method call that you do on it.
Stub just holds data that you provide and are presented to the SUT.
Both mock and stub are stand-ins for dependent on components (DOC) or collaborators for the SUT.
There is also a Spy which is in fact a wrapper around an actual implementation, that allows you to observe what goes in (method call+ parameters) and comes out of (return values) of the real object while it is used by the SUT. You can make the spy only spy on certain method calls, and leave the rest unchanged.

Lets see what this looks like in code.

public interface Printer {

    void println( String print );

    /**
     * Make it deal with objects too.
     * @param o to print.
     */
    default void println( Object o ) {
        printLn( o.toString() );
    }
}

Now over to the test class, which creates a mocked printer and hands it to the Business class.

    @Test
    public void doesItPrint() {
        Printer pr = mock( Printer.class );  1

        Business b = new Business( pr );     2

        b.work();                                 3

        verify( pr ).println( anyString() ); 4

    }

This is of course a simple test and the only thing that it verifies is that the printer.printLn(String) has been used.

@Mock
Printer printer; 1

Business business;

@BeforeEach
void setup() {
    business = new Business( printer );  2
}

@Test
void doesItPrintBusiness() {
    var lineCaptor = ArgumentCaptor.forClass( String.class ); 3

    business.work( "Linda" ); 4

    verify( printer ).println( lineCaptor.capture() ); 5
    assertThat( lineCaptor.getAllValues() ).contains( "Hello Linda" ); 6
    //  fail("test does It print ended. You know what to do.");

}

Mockito is well documented with lots of examples in its java doc. When you look to the test dependencies of your Maven project in NetBeans-IDE, right-click on the mockito dependency, then download the javadoc, you can enjoy that while you are developing.

To Mock or To Configure

Sometimes the class that you want to pass as a mock to the business code has a big interface, with many methods, and you do not want to restrict the business code to just a few trained methods. That would constrain the methods that the business class could use, which serves no real purpose. In such cases it may be better to provide a differently configured real class.

class PrintingBusiness
      final PrintStream out; 1

      PrintingBusiness() { 2
          this( System.out );
      }

      PrintingBusiness( PrintStream ps ) { 3
          this.out=ps;
      }

      void businessMethod(){
          out.format( "%s at %d", "Oplegkaas", 957 ); 4
      }
}

    @Test
    public void tformattedPrint() {
        ConsoleOutput cout = new ConsoleOutput();
        PrintStream out = cout.asPrintStream();

        out.format( "%s at %d", "Oplegkaas", 957 );

        assertThat( cout.toString() ).contains( "at", "Oplegkaas", "957" );
    }

@FunctionalInterface
public interface AppendAndClear {

    /**
     * Append a string to this AppendAndClear.
     *
     * @param toAppend text to add.
     */
    void appendText( String toAppend );

    /**
     * Clear the output. Optional operation.
     */
    default void clear() {
    }
}

package consoleoutput;

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.io.PrintStream;
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;

/**
 * Test helper, to be able to redirect a PrintStream to any writable.
 *
 * Use case: write to string or StringBuilder for test or e.g. javafx
 * TextInputControl for UI. Implement AppendAndClear (which can be done as a
 * lambda) and you're set.
 *
 * @author Pieter van den Hombergh {@code <p.vandenhombergh@fontys.nl>}
 */
public class ConsoleOutput extends OutputStream {

    protected final ByteArrayOutputStream baos = new ByteArrayOutputStream();
    final AppendAndClear aac;

    /**
     * Create a Console output copying data to given AppendAndClear.
     *
     * @param ta append and clear to copy all written text to.
     */
    public ConsoleOutput( AppendAndClear ta ) {
        this.aac = ta;
    }

    /**
     * Without appendable.
     */
    public ConsoleOutput() {
        this( null );
    }

    @Override
    public void write( int b ) throws IOException {
        if ( aac != null ) {
            String s = "" + ( (char) b );
            aac.appendText( s );
        }
        baos.write( (byte) b );
    }

    /**
     * Clear and discard output.
     */
    public void clear() {
        if ( aac != null ) {
            aac.clear();
        }
        baos.reset();
    }

    /**
     * Get the accumulated string since start or clear.
     *
     * @return the string
     */
    @Override
    public String toString() {
        return new String( baos.toByteArray(), StandardCharsets.UTF_8 );
    }

    /**
     * Factory method to get this ConsoleOutput as PrintStream.
     *
     * @return the print stream.
     */
    public PrintStream asPrintStream() {
        return new PrintStream( this, true, Charset.defaultCharset() );
    }
} // eof ConsoleOutput