This website provides the up to date information on course material, exercises and announcements about Software Engineering, Testing

The module description can be found here .

The book used in this semester is Practical Unit Testing with JUnit and Mockitio

The theory exam will be based on the book, mentioned above. Chapters covered are 1-5 inclusive. (from basics Unit testing till Mockito)

Study the theory/ tutorials before you come to class. This will make the lessons most effective, because the questions that you might have from studying could be answered immediately.

The performance assessment for JAVA2 and SEN1.

The solutions to the exercises will published in the Shared JAVA2-SEN1 Practicum Repository after the hand in deadline. You can also find the lesson examples there.

You should add your questions to the qanda repo questions and answer section in the same repository. The results can be found at Q&A (Login required and 2017 java2 student required).

1. Part 1, 1st 7 weeks

1.1. Why test: an introduction

Introduction it testing. The lesson slides .

Practical task: Test Driven stack and start project NetBeans Start Project

1.2. Static test with compiler and friends

In particular in strictly typed languages, the compiler already catches a large number of potential errors. There is more, for instance checkstyle, findbugs and pmd, which are all static test tools.

Static test tools actually inspect the code without running it. This is called static analysis.

  • checkstyle has a focus on code style, including documentation style.

  • pmd checks against suspect constructions, looking at the source code. It finds things suchs as potential null pointer dereferences.

  • findbugs does something similar and finds more problems. Findbugs looks at the compiled code but also does not run it.

1.3. Maven as a build tool.

We use maven as the preferred build tool for our projects.

The slides.

Further reading[Maven in 5 Minutes and then continue from there.

1.4. Mockito, mocks and spies.

See CSVObjectStream exercise in Java2. Devise tests to see that it works with different types.

1.5. Develop a Course planning

Demo topic of week 5.

In this lecture we want to create a course planning system.

The elements to be planned are

  • Students the audience in a lecture. The most important, because they pay.

  • Teachers The artists

  • Courses The topics

  • Rooms The locations

Let us call the event that needs all four of the above Lecture.

Let us start investigating what we need. Start with a blank sheet of paper or a white board.

1.6. Getting started with Mockito

The slides

1.7. Equivalence testing and boudnary analysis

The slides

2. Readability of test code

Test code (your unit tests, integration test) should have the same readability and understandability as normal code. Sometimes you must spend some extra time to ensure that the code is concise and well readable.

For instance, compare

assert just using JUnit standard asserts.
  assertEquals( 4, resultBooks.size() );
  assertEquals( books.get( 1 ), resultBooks.get( 0 ) );
  assertEquals( books.get( 8 ), resultBooks.get( 1 ) );
  assertEquals( books.get( 9 ), resultBooks.get( 2 ) );
  assertEquals( books.get( 10 ), resultBooks.get( 3 ) );
assert using AssertJ
  Assertions.assertThat( resultBooks )
            .containsExactlyInAnyOrder( book( 1 ), book( 8 ), book( 9 ), book( 10 ) );

Not only is the test in the second case more readable, but also better, as in more to the point. The first test may be over specific. If the order is not relevant, than do NOT make it part of the test spec.

Even more important is that the message on failure is much richer and very to the point, so that it is much easier to identify and find the problem.

Choose your test expressions with care. Avoid brittle tests, that fail because an irrelevant aspect of the implementation changed.