re: You don't know TDD VIEW POST

FULL DISCUSSION
 

Tests usually are kinda like "given X to ClassA.cat() it will call ClassB.fox() with X*Y"

In my opinion, this is a bad idea. A test should verify that a given function does what it was meant to do. Most of the time, the details of its implementation should not be part of the test. The approach you describe will make it easy to create passing tests even though the actual application logic doesn't work properly. It's also brittle: If you change the implementation of a function, the tests are likely to break, even if the contract that function fulfills remains unchanged.

There are cases where this kind of testing, using mocks, is appropriate. If your function interacts with an external system, then there is a decent chance that you should mock that out for testing purposes. For instance, a test may say "please make sure that the send_text_message function was called with the following parameters" -- but without actually running send_text_message. This is done when the external system may be unavailable entirely, or produces results that vary over time, or would slow down the test suite too much.

Over all though, I recommend that a test should call a given function, and then confirm that the return value of that function is what was expected, or at least that some state change resulting from that function call is what it should be.

code of conduct - report abuse