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 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.
1. Part 1, 1st 7 weeks
1.1. Why test: an introduction
Introduction it testing. The lesson slides .
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.
Further reading https://maven.apache.org/guides/getting-started/maven-in-five-minutes.html[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
Studentsthe audience in a lecture. The most important, because they pay.
Let us call the event that needs all four of the above
Let us start investigating what we need. Start with a blank sheet of paper or a white board.
1.7. Equivalence testing and boudnary analysis
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
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 ) );
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.