--- title: "Discussion About Pros and Cons of Unconstrained Frameworks" url: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/discussion-about-pros-and-cons-of-unconstrained-frameworks.md" canonical: "https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/discussion-about-pros-and-cons-of-unconstrained-frameworks/" tags: [] author: "Roy Osherove" description: "Lesson 19 of 21 in The Art of Unit Testing and TDD in Java (Day 3), 2:14. Free video by Roy Osherove." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Discussion About Pros and Cons of Unconstrained Frameworks 1. [Courses](https://courses.osherove.com/#courses) 2. [The Art of Unit Testing and TDD in Java](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/) 3. Day 3 Lesson 19 of 21 Duration: 2:14 [Watch on YouTube](https://www.youtube.com/watch?v=61oUXV-rrrU) Is it really easier and simpler to write tests for [legacy code](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-10 "Working with legacy code (The Art of Unit Testing, 2nd ed., ch. 10)") using [unconstrained frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-6#ch06lev1sec1 "Constrained and unconstrained frameworks (The Art of Unit Testing, 2nd ed., ch. 6)") 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](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-6#ch06lev1sec1 "Constrained and unconstrained frameworks (The Art of Unit Testing, 2nd ed., ch. 6)") 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](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12 "Working with legacy code (The Art of Unit Testing, 3rd ed., ch. 12)") 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](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-9 "Readability (The Art of Unit Testing, 3rd ed., ch. 9)") and [maintainability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8 "Maintainability (The Art of Unit Testing, 3rd ed., ch. 8)") that refactoring brings, so they should be used like a nuclear weapon. ## Transcript 348 words [\[00:05\]](https://www.youtube.com/watch?v=61oUXV-rrrU&t=5s) Okay, I want you to stop. Okay. How was that experience of working with [unconstrained frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-6#ch06lev1sec1 "Constrained and unconstrained frameworks (The Art of Unit Testing, 2nd ed., ch. 6)")? 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\]](https://www.youtube.com/watch?v=61oUXV-rrrU&t=44s) The reason is because the APIs that try to solve the problem of [legacy code](https://osherove.com/blog/2013/2/8/when-i-fight-with-legacy-code.html "When I fight with legacy code (osherove.com)") 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](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2 "The difference between mocks and stubs (The Art of Unit Testing, 2nd ed., ch. 4)") 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\]](https://www.youtube.com/watch?v=61oUXV-rrrU&t=76s) 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](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec5 "Variations on refactoring techniques (The Art of Unit Testing, 2nd ed., ch. 3)"), 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\]](https://www.youtube.com/watch?v=61oUXV-rrrU&t=114s) 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. ## Related - [Is Typemock too powerful? Will it kill design for testability?](https://osherove.com/blog/2008/1/17/is-typemock-too-powerful-will-it-kill-design-for-testability.html) · osherove.com Roy asks whether an unconstrained framework kills design for testability, the debate in this discussion. - [Pros and cons of designing for testability](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-11#ch11lev1sec3) · The Art of Unit Testing, 2nd ed., ch. 11 The 2nd edition's section on pros and cons of designing for testability versus faking legacy code as is. - [Alternatives to designing for testability](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-11#ch11lev1sec4) · The Art of Unit Testing, 2nd ed., ch. 11 Section on alternatives to designing for testability, where unconstrained frameworks are one option. - [Unreadable test code](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-5) · The Art of Unit Testing, 3rd ed., ch. 5 The 3rd edition's section on unreadable test code from isolation frameworks, the complexity noted here. ### Also linked in this lesson #### The Art of Unit Testing, 3rd ed. - [Working with legacy code](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-12), ch. 12 - [Readability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-9), ch. 9 - [Maintainability](https://livebook.manning.com/book/the-art-of-unit-testing-third-edition/chapter-8), ch. 8 #### The Art of Unit Testing, 2nd ed. - [Constrained and unconstrained frameworks](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-6#ch06lev1sec1), ch. 6 - [Working with legacy code](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-10), ch. 10 - [The difference between mocks and stubs](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-4#ch04lev1sec2), ch. 4 - [Variations on refactoring techniques](https://livebook.manning.com/book/the-art-of-unit-testing-second-edition/chapter-3#ch03lev1sec5), ch. 3 #### osherove.com - [When I fight with legacy code](https://osherove.com/blog/2013/2/8/when-i-fight-with-legacy-code.html) [Previous lesson Throw Errors with Powermock](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/throw-errors-with-powermock/) [Next lesson Continuous Delivery](https://courses.osherove.com/courses/the-art-of-unit-testing-and-tdd-in-java/continuous-delivery/) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/