Simon Wacker

When your boss confronts you with a task you must handle, the first thing you do is thinking about it. You mediate on the task and try to find the best solution of doing it. You maybe draw some sketches to visualize the whole thing and get a clearer image.
But, what’s next? - Well, when practicing TDD the next thing (actually the first, but I’m not that pragmatic about it) is to write a test for the central class and methods. This helps a lot because, when writing a test you become aware of collaborators, you test all special cases and you do not introduce unnecessary complexity. You basically create the whole api and implementations by working with them, which leads to an easy to use api that is based on a practical ground.
That’s basically all about it.
You first write your tests for a method of a class, and then the actual method based on the test, until the test executes without causing errors. Then the test for the next method and so on. It’s an easy, intuitive (when you are used to it) and safe way of programming which leads to stable and easy to use code. Another bonus is that when you refactor your code, improve its performance or do some other changes you can always run the tests to see if everything is still working.
This article is supposed to be a practical one (at least that’s what the headline says), thus we will jump right into practicing TDD. All you need is the as2lib’s unit testing framework and the mock objects framework from the last article Unit Testing: Mock Objects Framework.
A request came from a bank that needs an application to do their banking transactions like transfering money onto an account. The account seems to be the central problem domain (btw. we are only going to build the domain model). The bank clerk must be able to book money to an account (credit) and to withdraw money from an account (debit). That said we can start writing our tests for the account’s constructor and the methods credit and debit. We will start with the constructor tests.

We want the account’s constructor to take no arguments and set the balance to zero. To be able to control that the balance is zero we need the ,getBalance’ method. But the compiler won’t compile. That’s because we have not created the ,Account’ class yet. That’s what we are going to do now, based on our first test.

The compiler does not complain anymore and when we execute the test everything seems to work.
To execute the test you need a fla with the following code in the first frame.

It’s time to write the test for the ,credit’ method.

The credit method takes one argument ,amount’. Thus the first thing to test is what happens if we pass-in an ,amount’ of value ,null’. I want the method to just do nothing. That means that after invoking this method the balance should still be zero.
To satisfy the compiler and the test we implement the ,credit’ method.

Everything works fine now and we are ready for the next test that passes an amount of 40.

Executing the test fails. We need to do some major changes. To get it working we must be able to change the balance through the ,credit’ method dynamically.

When we run our test again we get the following output:

Out ,credit’ method does something wrong. It adds the amount to the balance even if it is ,null’. We have to prevent this.

We enhance our ,testCreditWithRealAmount’ test and add a new one to be really really sure that everything works as expected.

A business rule prescribes that the boss of the bank shall get notified if someone credits an amount that’s bigger or equal than 1 000 000 dollars to thank this guy personally. That notification is an email to the boss.
There already exists support for sending emails. This support is based on the ,EmailSender’ interface.

We write a test for the ,credit’ method in which we verify that the email sender’s ,sendEmail’ method gets executed when we credit an amount bigger than 1 000 000 dollar.

Because we are trained now we can make bigger steps and implement mutliple tests at once. The compiler complains because we have no method called ,setEmailSender’. Thus we introduce this method first.

When we run the test again we get the following output:

There’s still the sending functionality missing. We add it.

Executing the tests causes no errors now.

That’s it.
But there are still some things that we have not considered yet. What is if an email sender of value ,null’ gets set? What is if someone ,credits’ a negative amount?

In real life as you get more experienced writing tests and writing code you will just skip some of the little steps and combine them.

Download the sample code for Unit Testing with Mock Objects in Practice and Test Driven Development (TDD).
Download the as2lib snapshot from the 01.01.2005 which contains the unit testing and mock objects frameworks.

Unit testing means testing a class in isolation. To be able to do this any collaborator must at least be replaced by some kind of stub implementation of it. While this is definitely a good thing and appropriate in some cases it is really awkward if you have many collaborators and if these collaborators have a rather large number of methods.
Another problem with stubs is that they are not flexible enough to meet every use case, especially the special ones that hardly ever occur (except you spent hours programming the stub).
Thus you need a more general and dynamic approach.

The solution is: Mock Objects.

Mock objects also take unit testing a step further. You do not just create a stub that acts as if it were real, you also verify that the class under test collaborates with the mock object in the expected way. That means for example that the class under test calls certain methods with certain arguments on the mock object.
To work efficiently with mock objects you of course need a framework that gives you the ability to create mock objects and work with them easily.
This article is about such a framework that is based on the approach the EasyMock Framework uses. So, if you have ever worked with easymock (it’s for Java) you should have no problem working with this one. The basic workflow is as follows:
Create a mock control for a specific class or interface, get the mock object from it, set your expectations, set the behavior of the mock object, switch to replay state, use the mock object as if it were a normal instance of your class and verify if all expectations have been met.
While this sounds a little complicated and awkward at first sight it really is not. Just take a look at the following demonstration:

If any expectation has not been met an AssertionFailedError gets thrown that explains what went wrong. In the above case no AssertionFailedError should be thrown because every expectation has been met but it hadn’t if we had called the getStringProperty-method only once on the myMock-mock.

There is much more that can be done with the framework but just refer to the api documentation that is included in the download (I generated it with the old version of as2api because the new does not work and it is thus a little complex. It may be clearer to open the as-file directly and take a look at the documentation there.).

Download the Mock Objects Framework for Flash (It’s actually a snapshot of the as2lib from the 01.01.2005. The mock objects framework is contained in the org.as2lib.test.mock package).