The strategy laid out in Testing strategy for validation and action methods calls for a single test per action method, to show that it actually calls the validation method.
With an exception throwing validation method that test is simple. But with error code returning validation – there is no exception to wait for!
And this time you are not so lucky that your validation method has some other side effect that you can check for. So you can’t even use the method discussed in How to ensure a validation method is called that doesn’t throw exceptions!
No need to panic.
The answer lies in the the remainder of the test strategy: the tests you write to check each action method’s behavior given both valid and invalid input. To check that the validation method is called you simply check for the behavior expected for either valid or invalid input.
But, wait…
Doesn’t that mean the single test to show the validation is called, replicates one of the tests to check the action methods behavior?
Sure does!
Isn’t that bad? A gross violation of DRY?
Don’t think so.
It may FEEL wet, but it isn’t.
The intention of a test to show a method is called and of a test to verify the behavior given valid or invalid input, are miles apart. Tests do not just (!) verify behavior. They also serve as documentation of every aspect of your class’ behavior. Each test represents a different piece of knowledge about your class.
And that is also why you name each test in a way that reflects exactly what aspect of your class’ behavior it is verifying.
The fact that the test to show a method is called may have (almost) the same implementation as a test to verify the behavior given invalid or valid input, is therefore an … implementation (sic) detail and – in my not so humble opinion – totally irrelevant.
That’s it. Enjoy!
What code had you wondering how to test it? I’d love hearing from you by email or in the comments below. I read everything and will try to help where and as best I can.
Leave a Reply