How to unit-test sequential logic?

Question

Suppose I have class Car with following methods:

• LoadGasoline(IFuel gas)
• InsertKey(IKey key)
• StartEngine()
• IDrivingSession Go()

the purpose of Car is to configure and return an IDrivingSession which the rest of the application uses to drive the car. How do I unit-test my Car?

It looks like it requires a sequence of operations done before I can call Go() method. But I want to test each method separately as they all have some important logic. I don't want to have bunch of unit-tests like

Test1: LoadGasoline, Assert

Test2: LoadGasoline, InsertKey, Assert

Test3: LoadGasoline, InsertKey, StartEngine, Assert

Test4: LoadGasoline, InsertKey, StartEngine, Go, Assert

Isn't there a better way to unit-test sequential logic or is this a problem with my Car design?

--- EDIT ---- Thanks for all the answers. As many noticed, I should also have tests for invalid scenarios and I have those too, but this question is focused on how to test the valid sequence.

Answer 1

Why don't you want all those tests?

Go has very different behavior if you call it before or after, say, InsertKey, right? So you ought to be testing both behaviors, in my opinion.

Answer 2

Its a fair reluctance but sometimes thats what you need to do. If you can't fake out the system under test so it thinks its in a later state, then you need to go through the same steps to get it into that state. Without knowing more about what your testing its not clear how you could fake out the different states.

One way you can make this tolerable is use an extract method refactoring on tests for one state so that same code can be used to prepare the next test.

Answer 3

I would probaly have

Test 1: LoadGasoline, Assert, InsertKey Assert, StartEngine Assert, Go Assert
Test 2: LoadGasoline, Go, Assert
Test 3: Go, Assert
Test 4: StartEngine, Go, Assert

Depending on the actual object, I would probally not try and do all permutations, but I would have a single test that hits the success track, then I would tests that hit my fringe cases.

Edit:

After some thought I might have tests like:

• Start a car key that has no gas
• Start a car with gas, and wrong key
• Start a car with gas and right key (Test 1 above)
• Push Peddle before starting car.

Answer 4

Some unit testing frameworks let you specify set-up code which runs before the actual test starts.

This allows you to get the target object into the proper state before running your test. That way your test can pass or fail based on the specific code you're testing rather than on the code needed before you can run a test.

As a result, your test sequence will wind up something like this:

Test1: 
    LoadGasoline, Assert

Test2 Setup:
    LoadGasoline

Test2:
    InsertKey, Assert

Test3 Setup: 
    LoadGasoline, InsertKey

Test3:
    StartEngine, Assert

Test4 Setup: 
    LoadGasoline, InsertKey, StartEngine

Test4:
    Go, Assert

Realistically speaking, since the tests are all run in sequence there's no chance of Test's Setup failing if the previous test passes.

With that said, you should also test failure cases that aren't expected to work but that's a different issue.

Answer 5

I think each method should be tested separately and independently.

IMHO, you should prepare the environment for each case, so only the LoadGasoline test will break if you change the LoadGasoline method, and you won't need to see all the tests break because of a single bug.

I don't know how the state of your Car looks like, but, before the InsertKey, you should prepare with a method like, car.SetTotalGasoline(20); or whatever variable is set in this method, but not depend on a complex logic of the method LoadGasoline.

You will later need a test (in this case, not a unit test) to test all the sequence.

Answer 6

Technically you should use the following tests at least:

testLoadGasoline

testInsertKeyGasolineNotLoaded

testStartEngineKeyNotInserted

testGoEngineNotStarted

testGo

If you can directly view intermediate steps you can add

testInsertKeyGasolineLoaded

testStartEngineKeyInserted

Note that if you can directly set the state (which is language and design dependent), then testInsertKeyGasolineLoaded might not actually call LoadGasoline.