---
title: "Test maintainability: consider creating a test fixture \"per method\" instead of \"per class\""
url: "https://osherove.com/blog/2005/4/11/test-maintainability-consider-creating-a-test-fixture-quotpe.md"
canonical: "https://osherove.com/blog/2005/4/11/test-maintainability-consider-creating-a-test-fixture-quotpe.html"
published: "2005-04-11T14:26:00"
updated: "2005-04-11T14:26:00"
tags: ["Agile Related", "Testing Guidelines"]
author: "Roy Osherove"
description: "If you find yourself writing lots of tests for a single method on your tested class - consider making a specific fixture for just one method or feature. It would make the class more maintainable and logically sound. For…"
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/"
---

# Test maintainability: consider creating a test fixture "per method" instead of "per class"

By Roy Osherove April 11, 2005 In [Agile Related](https://osherove.com/blog/category/agile-related), [Testing Guidelines](https://osherove.com/blog/category/testing-guidelines)

**Historical article** · Originally published April 11, 2005; technical details may be outdated.

If you find yourself writing lots of tests for a single method on your tested class - consider making a specific fixture for just one method or feature. It would make the class more maintainable and logically sound. 

For example, a complex Login class might have one "IsLoginOK" method that has dozens of unit test for various logical angles and features.

You might have a fixture that looks like this:

**\[TestFixture\]**

**public class LoginManagerTests\_IsLoginOK**

**{**

   **\[Test\]**

   **public void ReturnsFalseOnNonExistingUser()**

   **{**

   **...**

   **}**

**}**

note that:

- The class name suggests the main feature or function being tested by postfixing it to the name
- The is no need to prefix methods in the class with the method name since it is clearly the only method being tests. Each test case is a variation of feature of this method.
- You might end up with multiple class test fixtures for one tested class. That's OK, just remember to put them under a specific folder in your test project with the name of the tested class like this

- ProjectName

- LoginManagerTests

- **LoginManagerTests\_IsLoginOK**
- **LoginManagerTests\_ChangePassword**
- **LoginManagerTests\_General**

- You would probably end up with a class that tests various "small" features which were left over from other fixtures. name it to \[TestedClass\_General\] or \[TestedClass\_Misc\] so that it's testing purpose is understood. 

## More in Agile Related

[All posts in Agile Related](https://osherove.com/blog/category/agile-related)

- Apr 14, 2005

    ### [Setting Up VirtualMock in the Eclipse IDE](https://osherove.com/blog/2005/4/14/setting-up-virtualmock-in-the-eclipse-ide.html)

- Apr 11, 2005

    ### [Another Entlib example: Separate integration tests from unit tests (and learn to know the difference)](https://osherove.com/blog/2005/4/11/another-entlib-example-separate-integration-tests-from-unit.html)

- Apr 11, 2005

    ### [Enterprise library -- Test usability and "runnability"](https://osherove.com/blog/2005/4/11/enterprise-library-test-usability-and-quotrunnabilityquot.html)

- Apr 10, 2005

    ### [Making your tests withstand design and interface changes - remove code duplication](https://osherove.com/blog/2005/4/10/making-your-tests-withstand-design-and-interface-changes-rem.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/