This topic is very much related to that of testing behavior versus implementation. In this case, the examples given are very simple. What if your process function looked more like this :
In this case, would it not be acceptable for your unit test to validate that the secondPart's process method is being called with the result of the firstPart.process as parameter? Or perhaps a slightly more complex case, one where the Processor modifies the result from the firstPart's process and passes that to the secondPart.
Writing unit tests that are not change detectors sounds like a good objective. But, when coding in a system that is very service oriented, it is not always possible to write unit tests that are not change detectors and that test only behavior as opposed to implementation. In those cases, writing tests that validate function calls seems like the fastest way to achieve confidence that your code works.
There are also other aspects on testing than just running your code. Good written tests document your code and help others getting around. Tests provide a safety net for refactoring. Change-detector tests as described above do not add any clarity, and you cannot safely refactor stuff if you know for sure that you need to adapt the tests afterwards to get them passing again.
When you think about your example: can you really be "confident that your code works"? What if someone completely changes firstPart - your test would still pass, because you mock everything, even if the process function might not work anymore.
This topic is very much related to that of testing behavior versus implementation. In this case, the examples given are very simple. What if your process function looked more like this :
ReplyDeletedef process(w: Work)
firstResult = firstPart.process(w)
secondPart.process(w, firstResult)
In this case, would it not be acceptable for your unit test to validate that the secondPart's process method is being called with the result of the firstPart.process as parameter? Or perhaps a slightly more complex case, one where the Processor modifies the result from the firstPart's process and passes that to the secondPart.
Writing unit tests that are not change detectors sounds like a good objective. But, when coding in a system that is very service oriented, it is not always possible to write unit tests that are not change detectors and that test only behavior as opposed to implementation. In those cases, writing tests that validate function calls seems like the fastest way to achieve confidence that your code works.
There are also other aspects on testing than just running your code. Good written tests document your code and help others getting around. Tests provide a safety net for refactoring. Change-detector tests as described above do not add any clarity, and you cannot safely refactor stuff if you know for sure that you need to adapt the tests afterwards to get them passing again.
DeleteWhen you think about your example: can you really be "confident that your code works"? What if someone completely changes firstPart - your test would still pass, because you mock everything, even if the process function might not work anymore.