Introduction to Test Suites and Project Management

Contents

• Software Lifecycle
• Zoom onto the Implementation Phase
• Zoom onto the Testing Phase
• The Monopoly Engine

Software Lifecycle

You start on the upper left corner and hopefully, you will arrive at the bottom right corner someday.

At every step, you do the V&V:

Verification:

You check that you are building the system correctly (i.e. it works);

Validation:

You check that you are building the correct system (i.e. the one the customer ordered).

If you ever wondered why we are doing something silly like this monopoly program instead of doing something useful and serious, like, say a course roster system, then the answer is simple:

The monopoly project is one of the rare projects where the waterfall model works.

• We have immutable rules of the game.
• We have a physical model to refer to.
• We have millions of content users.

Later, in the fourth year Software Engineering Course, you will get to analyse and disect the waterfall model and learn about more realistic ways of creating software.

Zoom onto the Implementation Phase

This tool allows us to decompose the whole implementation process into many tiny steps which can be done simultaniously by different people. These steps are called changes.

Every project will start out with a baseline, that is a small embryo of the monopoly program of which you know that it works.

The members of the project group will then select a change to work on. Some changes depend on succesfully completing previous changes, others can be done independently.

When a change is completed, your instructors will review your code and, if they accept it, will proceed to integrate it into the baseline, creating a new base for the next changes:

Zoom onto the Testing Phase

With every change will come a supply of tests that your monopoly program has to survive before your change may be submitted for review.

Aegis supports three kinds of tests:

Change Tests:

You run the change-specific tests on your newly created code. This is the most straightforward thing.

Regression Tests:

You run all of the previous tests on your newly created code. This checks that you didn't break anything that used to work.

Baseline Tests:

This is like "testing the tests". You run the new tests on the old baseline code. These tests should fail, as they should check for functionality that doesn't exist in tghe baseline code.

In this project, the tests will be supplied to you. In real life, you would have to write the tests yourself. Testing, of course, can't garantee that the software will work 100%, as it only checks for the absence of very specific bugs. There are, of course, techniques to judge the reliability of tests, but these are not the focus of this lecture.

The Monopoly Engine

The monopoly engine reads an input file. This file contains the game state and the moves of the players. The engine analyses the player's moves and then changes the game state accordingly. The result is finally placed into the output file.

A complete monopoly program would, of course, require a better interface than a text editor. This interface could be implemented in a similar way, taking the output of the monopoly engine and displaying it graphically on the screen and translating user input into a file format that the monopoly engine understands.

The reason why we will not do the interface is mainly for simplicity. It is very hard to automate the testing of a (graphical) user interface.

A further advantage of splitting up the monopoly program into an engine and a GUI is that by implementing and testing the engine first, the testing of the GUI is very much simplified: if there's a bug, it has to be in the GUI, since we know that the engine is reliable.