Lesson 19 of 21
Discussion About Pros and Cons of Unconstrained Frameworks
Is it really easier and simpler to write tests for legacy code (external link, opens in new tab) using unconstrained frameworks (external link, opens in new tab) in Java? Is it easier and simpler to refactor the code? Let`s talk about it.
In this lesson
After the exercises Roy Osherove asks how unconstrained frameworks (external link, opens in new tab) felt, concludes that they were much more complicated than refactoring, and explains that an API for faking private and static methods, constructors and other legacy code (external link, opens in new tab) features has to be as complex as legacy code. He says tools like PowerMock and JMockit let you test code without changing it but give up the readability (external link, opens in new tab) and maintainability (external link, opens in new tab) that refactoring brings, so they should be used like a nuclear weapon.
Transcript
[00:05] (external link, opens in new tab) Okay, I want you to stop. Okay. How was that experience of working with unconstrained frameworks (external link, opens in new tab)? Did they unconstrain you? Did they complicate or simplify? Complicate. They were much more complicated than refactoring. And one of the things I wanted you to realize is that the fact that some frameworks can actually do these things doesn't actually mean that they help us. So I would say that most of the time, especially in Java with the current frameworks that we have, it's not always a good idea to use something like PowerMock or JMockit.
[00:44] (external link, opens in new tab) The reason is because the APIs that try to solve the problem of legacy code (external link, opens in new tab) have to be as complex as legacy code because legacy code has a lot of features. For example, private methods, you need to have an API to fake (external link, opens in new tab) a private method. Static methods, you need to have an API for that. Private static methods, you need to have an API for that as well. What about constructors? You need to have an API for faking a constructor. future objects, static constructors,
[01:16] (external link, opens in new tab) Okay, collections, arrays, all the things that it tries because they can handle so many things. They the API also has to handle all these things that makes the API almost like a dictionary. You have to look things up all the time and the code can become pretty horrible. When we were using extract and override (external link, opens in new tab), our code and our tests were so simple and once you got it working, it was very easy to write new new tests. Now, if you learn the API for things like PowerMock, you will be able to test these things without changing them, but you're not getting any benefit from it.
[01:54] (external link, opens in new tab) You're not getting the benefit of refactoring your code to be more readable and more maintainable. You might actually be also making your tests less readable and less So there is a big trade-off here. Only use these things like a nuclear weapon and realize that it's going to hurt the environment just as much as it helps you.