单元测试和断言void方法的案例

Question

I'm trying to create some unit testing for a void method. Basically the method is intended to show the role of a system user and implement it within the software.

This is the method:

public void setPersonObj(Person typeObj)
{
    this.typeObj = typeObj;
    createMain();
}

How would I create an assert case in a separate class that uses unit testing to check this method?

Many thanks

Answer 1

If the method is void it clearly has some side-effects. Otherwise it would be a no-op. So you have no choice and need to validate these side-effects.

How to test these side effects is dependant on technology you use and testing approach:

• if the method calls some other collaborators/objects, mock them and verify mocks afterwards

• if it changes the state of some other components (adding element to collection, modifying field) query and assert them

• if it stores something on the disk/database, query them as well

• if it display some window in Swing, you need to use Swing testing frameworks like Window Licker

• if... you could provide some more technical details ?

BTW A setter that performs some extra unrelated logic is a code smell. People maintaining such code will find it really hard to figure out that this innocent setPersonObj() does something except... setting.

Also all these names: Person , PersonObj and typeObj should be the same for consistency and compatibility with JavaBean specification.

Answer 2

There are basically two different philosophies when unit-testing.

• Testing the state of your class under test. You typically run the method you want to test, and check that the class under test has the correct state after it ran, using getters on it, or the value being returned by the method itself. In this scenario, it may be a bit difficult to test a void method, as you may be forced to add getters just for your test, and it would break encapsulation. So don't do that. An alternate way is to use state-capturing stub classes as your dependencies, but this can be fishy as your stub themselves contain some untested logic.

• Testing the behaviour of your class under test. While running the method you want to test, you set expectations on the dependencies of your class. This is typically achieved using mock frameworks . In this scenario, you basically don't care whether your method return a value, or is void. What's important is what methods are being called on your dependencies, and with which parameters. This is what you want to do, a far more efficient way of testing (and usually provides better coverage). Using this way of testing consistently also ensures your design is good and proper OO (forces you to do dependency injection, etc.)

Answer 3

It depends what the createMain() method does. For example, if the method sets the value of a String field in the class, your unit test should check to make sure that the String field was set to the correct value.

Your unit test could also check to make sure the typeObj field was set (by calling its corresponding getter method).