Книга состоит из 4 разделов: базовые принципы, моки и стабы, тестируемый код, внедрение тестирования в легаси среде. И если первые два раздела я уже освоил, достаточно натанцевавшись по граблям (читал чтобы убедиться, что ничего не пропустил), то последние дали богатую пищу для размышлений.
A unit test should have the following properties:
❂ It should be automated and repeatable.
❂ It should be easy to implement.
❂ Once it’s written, it should remain for future use.
❂ Anyone should be able to run it.
❂ It should run at the push of a button.
❂ It should run quickly.
These are the FICC properties: fast, isolated, configuration-free, and consistent. If it’s hard to write such a test, or it takes a long time to write it, the system isn’t testable.
Противоречие между инкапсуляцией и тестируемостью решается очень легко:
Some people feel that opening up the design to make it more testable is a bad thing because it hurts the object-oriented principles the design is based on. I can wholeheartedly say to those people, “Don’t be silly.” Object-oriented techniques are there to enforce some constraints on the end user of the API (the end user being the programmer who will use your object model) so that the object model is used properly and is protected from unforeseen ways of usage. Object orientation also has a lot to do with reuse of code and the single-responsibility principle (which requires that each class has only a single responsibility). When we write unit tests for our code, we are adding another end user (the test) to the object model. That end user is just as important as the original one, but it has different goals when using the model.
Ну и, в заключение, совет от Мастера: Finally, as a friend once said, a good bottle of vodka never hurts when dealing with legacy code.
