Replacement of Algorithm Testing with Testing of Effects Being Inserted

Total: 2 Average: 4.5

As I expected, Rule 8 from the article “Rules for Implementing TDD in Old Project” stating that we don’t need to test the algorithm of methods raised many “how” and “why” questions. When writing the previous article, it seemed obvious to me, so I did not go into much details on the matter. In this article, I provide a small sample code and two examples of how it could be tested.

The “Do not test the algorithm of methods” from the previous article says:

Some people check the number of calls of certain methods, verify the call itself, etc., in other words, check the internal work of methods. It’s just as bad as testing of the private ones. The difference is only in the application layer of such check. This approach again gives a lot of fragile tests, thus some people do not take TDD properly”.

There is a handler code:

It is necessary to test the Handle() method. Make sure that the DbCommands and MessagingLogger methods were called.

“Mock” Approach

It would pass the mocks of the corresponding interfaces to the class constructor, and then check whether the corresponding methods were called: SaveEvt(), Received(), or InvalidEvent(). The code would look something like this:

“Non-mock” Approach

It would create fake objects and check whether the event and not the method call, occurred. In this case, the code would be something like:

And the fake-objects methods would look like this:

IsEventSaved would be declared only in a fake object.

Advantages and disadvantages

The first approach is simple and fast, but if you need to change methods, call one instead of the other in the same situation, then it would be necessary to modify the tests.

The second approach leads to the creation of additional entities, and you get the benefit only in the situation with the replacement of methods. In this case, perhaps, you will not even have to change anything in Fakes, or in tests. Another advantage, more idealistic, is that you make the test so that it does not know about the internals of the test method. Therefore, personally I, if time permits, do tests for fakes.