Foundations of Programming - Karl Seguin

Chapter 4 - Dependency Injection
Sneak Peak at Unit Testing
Talking about coupling with respect to unit testing is something of a chicken and egg problem – which to
talk about first. I think it’s best to move ahead with coupling, provided we cover some basics about unit
testing. Most importantly is that unit tests are all about the unit. You aren’t focusing on end-to-end
testing but rather on individual behavior. The idea is that if you test each behavior of each method
thoroughly and test their interaction with one another, you’re whole system is solid. This is tricky given
that the method you want to unit test might have a dependency on another class which can’t be easily
executed within the context of a test (such as a database, or a web-browser element). For this reason,
unit testing makes use of mock classes – or pretend class.
Let’s look at an example, saving a car’s state:
public class Car
{
private int _id;
public void Save()
{
if (!IsValid())
{
//todo: come up with a better exception
throw new InvalidOperationException("The car must be in a valid
state");
}
if (_id == 0)
{
_id = DataAccess.CreateInstance().Save(this);
}
else
{
DataAccess.CreateInstance().Update(this);
}
}
}
private bool IsValid()
{
//todo: make sure the object is in a valid state
return true;
}
To effectively test the Save method, there are three things we must do:
1. Make sure the correct exception is thrown when we try to save a car which is in an invalid state,
2. Make sure the data access’ Save method is called when it’s a new car, and
3. Make sure the Update method is called when it’s an existing car.
What we don’t want to do (which is just as important as what we do want to do), is test the functionality
of IsValid or the data access’ Save and Update functions (other tests will take care of those). The last
point is important – all we want to do is make sure these functions are called with the proper
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
27