Chapter 7. Points of Controversy

•The test code is more concise.

•The SUT is even more confusing than before …are we testing the real thing, or some strange artifact created by Mockito?

In conclusion, we may say that this technique is very similar to the one discussed previously (Section 7.6.3). The idea is the same: introduce changes to the SUT, and replace a part of it with some canned behaviour. With the previously presented technique, this was done by hand. In this section, we have learned how to do it with Mockito. There is no semantic difference between these two approaches. Some people feel that the first technique is better (probably because they have visible control over the subclassing of the SUT), while others will argue that the use of a framework makes things simpler by automating things which were done by hand. It is really hard to choose a winner here.

The thing to remember is that this technique allows for the testing of some cumbersome code, but does not make this code any better. If your aim is to verify things, this might be enough for you. If you want cleaner code, you should rather think about redesigning your classes, as discussed previously.

7.6.5. Conclusions

In this section, we have discussed various options for testing code which uses the new operator to create collaborators. Four different approaches have been discussed. Each of them had some pros and cons, which have been discussed in the sections above. Table 7.3 summarizes the salient features of each of the options on offer.

Table 7.3. Comparison of new operator testing approaches

•The PowerMock option is especially attractive when working with legacy code, which is something we cannot modify (or are too scared to modify…). Its selling point is its ability to test nasty code without any struggle.

168