Programme

The course consists of a mix of short presentations, live programming demonstrations, and lots of programming exercises. We will use Java for the examples and the practical exercises.

Course Introduction

Round of introductions; set expectations & collect issues; presentation Why unit testing? to see the short term and long term effects of unit testing from a systemic perspective.

Introduction to Test Driven Development

Experience the basics of test driven development; learn what makes a unit test.

Responsibility Driven Design with Mocking

Learn and experience the use of mocking techniques to write better isolated unit tests and to arrive at a more loosely coupled design; learn about the difference between interaction based testing and state based testing

Mocking Styles

Learn and experience different ways of creating mock objects; learn the difference between mocks, stubs, fakes, and dummies and when to apply them.

Getting Your Tests In: Breaking Dependencies in Code

Learn how to break dependencies in a responsible way; learn a number of refactorings that enable you to add tests to existing code without unit tests

Story Testing with RSpec

Get a fresh perspective on functional/integration/unit testing; RSpec is a behaviour driven development framework that can be used both for writing story tests and writing executable behaviour specifications for objects.

Closing Retrospective

Reflect on the learning experience, focus on bringing lessons learned to daily practice


We can adapt the programme if desired when we run the course in-house. Some alternative course components are:

Unit Testing Clinic

Learn how to solve specific problems from daily practice

Participants bring in examples of unit tests they have trouble with or code that is hard to unit test; we will discuss the issues, provide suggestions for improvement, and, whenever possible, help to make it work directly 

Right Sizing Your Unit Tests – what makes a good test?

By examining several code examples, learn to answer questions like: what is the right size of scope for a unit test? how does the design of production code affect test code and vice versa?