--- title: "The role of helper frameworks in your tests" url: "https://osherove.com/blog/2005/1/15/the-role-of-helper-frameworks-in-your-tests.md" canonical: "https://osherove.com/blog/2005/1/15/the-role-of-helper-frameworks-in-your-tests.html" published: "2005-01-15T16:10:00" updated: "2005-01-15T16:10:00" tags: ["Agile Related"] author: "Roy Osherove" description: "As you create tests for a system that gets bigger and bigger, so do the tests become bigger and more complex. One of the problems that start to occur is that you test code starts getting riddled with various…" 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/" --- # The role of helper frameworks in your tests By Roy Osherove January 15, 2005 In [Agile Related](https://osherove.com/blog/category/agile-related) **Historical article** · Originally published January 15, 2005; technical details may be outdated. As you create tests for a system that gets bigger and bigger, so do the tests become bigger and more complex. One of the problems that start to occur is that you test code starts getting riddled with various object-creation code. For example, you're testing a complex business object's state, to make it just right for testing an exception that should be thrown. That sort of creation can take many lines of code and might repeat itself in other tests too. This causes several symptoms: First, your tests are now much less readable than they should be. Tests should be readble so they can serve as part of the overall API documentation which can then be used by members of your team to familierize themselves with your code. Second, you're breaking one of the first rules of good code : "Don't repeat yourself". Duplication in your tests is just as bad as duplication in your prodcution code. In this case there's going to be lots of duplication in the creation and state-setting of your to-be-tested business objects. By refactoring, we can start removing this duplication into various helper methods that will be laid down within our test fixture. However, this still has the effect of making your test fixture do more than one thing (it's both a test fixture and a helper class now). Additional refactoring eventually leads us to create a helper class with specific helper methods (usually static) for the business objects under test. This "Pattern" of helper methods and factories for your unit tests is not new. It's been called several names ("[ObjectMother](http://www.thoughtworks.com/us/library/ObjectMother%20Website.pdf)" - PDF , for example) and eventually, most developers that implement unit tests arrive at the same conculsion, one way or the other. Assuming that most projects will have at least one such helper class, we can and should begin to realize and think about our helper factories and classes for testing as pure frameworks on which to build our tests. These frameworks can later be used to run not only our developer tests, but our customer tests as well (using FIT,  for example). Given the "organic" nature in which an agile software project usually grows, these frameworks are grown, and not pre-designed. As such, we should pay special attention to them as they are created and nurtured, and to make sure that once one has benn "born" we start thinking of it as a service to out tests, and to future tests as well. For example, there may be a good point in time where these factories and helpers will need to become a separate assembly in our tests, so that it can be re-used in other testing scenarios. We can also re-use these frameworks later adding more generality to them and thus making them easier to use with customer tests. These frameworks can be very small in small applications (one-two utility classes) or very big on large ones (hierarchical, categorized and refactored classes for each object type, test type and so on). One of the most important things to keep in mind as you build such a framework is to re0use existing methods to their smallest parts. That is, make your code inside those methods repeat itself exactly once. The minute ou break this rule you're heading down a path where future changes in your business objects might lead to big lengthy and painful changes in your helpers. If you keep the DRY rule, you'll most likely need to change very little creation code in order to support such changes. Even the acto of callin "new" on an object should be repeated only once and refactored into a method that will be re-used by all other helper methods. That way if your object loses its default constructor, for example, you need only change one simple method to factor the change into your helper framework. ## Lessons on this topic - [A DSL for our Tests](https://courses.osherove.com/courses/tdd-pairing-sessions-building-a-go-game/a-dsl-for-our-tests/) · TDD Pairing Sessions - Building a Go Game ## More in Agile Related [All posts in Agile Related](https://osherove.com/blog/category/agile-related) - Jan 23, 2005 ### [Agile content for the Winter 2004 issue of Methods & Tools](https://osherove.com/blog/2005/1/23/agile-content-for-the-winter-2004-issue-of-methods-amp-tools.html) - Jan 18, 2005 ### [Announcing: First Agile Israel user group meeting this month!](https://osherove.com/blog/2005/1/18/announcing-first-agile-israel-user-group-meeting-this-month.html) - Jan 11, 2005 ### [Agile Deployment](https://osherove.com/blog/2005/1/11/agile-deployment.html) - Jan 11, 2005 ### [\[Interview\] Jonathan de Halleux on mbUnit and model based testing](https://osherove.com/blog/2005/1/11/interview-jonathan-de-halleux-on-mbunit-and-model-based-test.html) --- ## 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/