If you ask me, this code looks much more readable and maintainable. Of course, life would be even better if we also didn’t have private methods. If nobody had the ability to reach the private method in any way, the Inspector anti-pattern in unit tests would not be possible. This coupling between the unit test BookTest and the class Book would not happen if it was not possible to use reflection in the first place. How can I trust it if it lies in such a simple scenario? I modify the code and I know that I didn’t break anything. The tests are not a “safety net” for me anymore. However, changing the test and at the same time changing main code is, I believe, a dangerous practice: most probably I will introduce some new bugs. What would I do next? I would have to roll back my changes and then start refactoring the test and the class, in order to get rid of this assumption. It’s just an assumption the test made about the internals of Book and this assumption has no reasons aside from “We didn’t have time to refactor the class and make System.out injectable.”īy the way, this testing approach is known as the “Inspector” test anti-pattern. Otherwise, why would a test demand anything from a private implementation of a class? Very soon, after some investigation I would find out that there is no reason. Why? What’s wrong with returning StringBuilder? I would think that there is some hidden reason for this. If it’s not my test or I wrote it a long time ago, I would be frustrated to learn this fact: the test expects me to write my private methods only one specific way. However, the test BookTest will fail, because it expects my class Book to have method name which returns String.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |