What are tests and why do we need them?

The way that you have worked with Java so far is that you had to write some code to implement something. For example you had to implement a bird watcher system or a telephone book, in which you could save people with their telephone numbers and look them up, too. You probably created classes called PhoneBook or BookEntry, and you had variables such as String personName, int phoneNumber and maybe a List or a Map which contained all the people and their phone numbers. You had to think about how the phonebook works, and then you added classes, fields (variables) and methods. Slowly but surely, your phonebook started to look more and more like a phonebook.

But how did you know that your phonebook was actually working? You could have implemented a method that didn’t work, or maybe you forgot to add people to the phonebook, so the data wasn’t actually stored. What you did was you ran the TMC tests. They kept telling you whether the phonebook was working as intended. The test said "when I look for Alice in your phonebook, I will receive Alice’s phone number 1234-567.". And if the test didn’t receive Alice’s number, it would turn red and say something like "I expected 1234-567. But I received 0042-987." Therefore, the test fails.

The tests were a really useful way for you to know that you were indeed implementing a proper phonebook. You could have just written empty classes and said "here is the phonebook!" and there would have been no way to verify that the phonebook works. The test made sure that this doesn’t happen. They also give you confidence as you code. Because every test that turns green gives you that little "yes!" feeling that you wrote something that works.

Thus, tests fulfill two functions at once: they constantly probe your implementation and check whether it works, and they make you feel more confident about your programming skills. That’s really neat!

When you were at school, you probably had to write an English exam at some point. You wrote your answers, and then the teacher graded your exam. The teacher is just like a test: she reads your exam, expecting the correct answer. For example, you wrote "Alice and Bob goes to school.". Your teacher would get the red pen and highlight the word "goes". The teacher says "I expected: Alice and Bob go to school. Instead, I received: Alice and Bob goes to school." The teachers expectation, or assertion, was not met. Therefore, you get an error. As you grow older and you become more proficient at English, you write Emails in English, perhaps for work or at university. When you make a mistake, you spot your own errors: "oh hang on, I have to use 'go' instead of 'goes' here." You have internalized a test that checks for the correct conjugation of the word. You know what to expect, and when you deviate from the expectation, you spot the error.

Many people work the same way when they write code. They say "I know what I am doing because I have experience and I know the rules." But of course, we always make mistakes. Our brains are really bad testers. We stop seeing mistakes because we feel so familiar with our code. Have you ever handed in a report for university, only to find that the lecturer finds spelling errors you swear you didn’t do? That’s what happens in programming, too.

That is why we write our own little annoying English teachers that constantly check: is this correct? Even though we know how to program, we also acknowledge that our brains are terrible testers for things that you write yourself, so we give our brains a break and write a test instead.

Test Driven Development (TDD)

In Week 9 we wrote a little phonebook and then we ran the test to check that the phonebook was working. That worked well, because we no longer have to rely on our brains to spot the errors on-the-fly. But here is another bad message: not only does our brain stop recognizing errors in our own code, but it is also automatically biased to want our own tests to pass. You spent all this time writing your phonebook, you know how it works, so you know what test to write for it.

But your brain secretly deceives you: you have implemented a phonebook, and this is the only phonebook that you know. What if you removed your code, but leave in the tests- and ask a friend to write a phonebook? They start complaining that your tests are unfair. "Why do I have to use a List? I use Maps!" your friend says. But your tests insists that the phonebook has a List. So what have you done? You have written a test that proves YOUR implementation is correct.

When you work test-driven, you don’t implement the phonebook and then test it. You first write the test for a phonebook, and then you implement it. That sounds a bit weird at first. Why write tests for stuff that’s not there yet? We know it’s going to fail! But this is what we want. We need to keep telling our brains: this does not work. Figure out a way to make it work. This way, it is much harder to get married to your own code and to stop seeing problems with your test. You have found a way to deal with the human brain. Congratulations!

Simple Tests

  car.start();
  assertThat( car.motorIsOn() ) 1
      .as("Motor should be on after start") 2
      .isTrue(); 3

  assertThat(car.speedLimit())
      .as("Make it a legal car?")
      .isEqualTo(250);

    assertThat( f1Champ ).isEqualTo( louis );
    assertThat( f1Champ ).isSameAs( louis );

Quiz: what is the difference between the two here: equals and same?

String Containment

  Student student = ....

  assertThat( student.toString() )
      .isNotNull()                              1
      .doesNotContainIgnoringCase("student{")    2
      .contains( "Harry", "Potter", "1980-07-31", "12345"); 3

How the string is formatted does not matter for this test to pass. It only requires the shown strings in any order.

Collection Containment

For collections, there are numerous tests. Collections in this context include everything Iterable, making it very powerful as can be seen in the Javadoc page of Iterable by following the link in this sentence. Look at the sub-interfaces and the implementing classes.

    List<Professor> professors = List.of( SNAPE, DUMBLEDORE, MCGONAGALL ); 1

    List<Professor> teachesTransfiguration = professors.stream()
            .filter( p -> p.teaches( "Transfigurations" ) ).collect( toList() );

    assertThat( teachesTransfiguration )
            .isNotNull()                         2
            .hasSizeGreaterThanOrEqualTo( 2 )    3
            .contains( DUMBLEDORE, MCGONAGALL ); 4

//  List<Student> hogwartsStudents = ...; 1
  List<Student> hogwartsStudents = List.of( HARRY, HERMIONE, RON ); 1

  assertThat( hogwartsStudents )
          .isNotNull()                                2
          .hasSizeGreaterThanOrEqualTo( 3 )           3
          .extracting( s -> s.getStudentNumber() )    4
          .containsExactlyInAnyOrder( 12346, 12345, 12347 ); 5

Assert Exceptions

In most business processes you want to avoid exceptions, but when they are expected, they must be thrown by the code under test, so that too needs to be tested.

There are three cases:

In AssertJ the exception testing helpers have a format that deviates from the assertThat().someCheck(…​) style. This inconsistency has to do with the way the exceptions causing code must be called, and cannot easily be avoided. We propagate one form, declaring a lambda first, and use that as the parameter to the exception asserter.

    @Test
    public void fileUsingMethod() throws IOException { 1
        Files.lines(Path.of ("puk.txt") );  2
    }

    Student draco = new Student("Draco", "Malfoy", LocalDate.of (1980,6,5));
    ThrowingCallable code = () -> {
        hogwarts.addStudent( draco );  1
    };

    assertThatCode( code)
            .as( "draco should be accepted to make the adventures possible")
            .doesNotThrowAnyException();

    @Test
    public void addIllegalProfessor() {
        var malfoy = new Professor( "Lucius", "Malfoy", LocalDate.of( 1953, 10, 9 ) ); 1

        ThrowingCallable code = () -> { 2
            hogwarts.addProfessor( malfoy );
        };

        assertThatThrownBy( code )
                .isInstanceOf( Exception.class) 3
                .isExactlyInstanceOf( IllegalArgumentException.class) 4
                .hasMessageContainingAll( "should","teach"); 5
        // fail( "addIllegalProfessor completed succesfully; you know what to do" );
    }