How to know if your Unit Test Fixture is “right-sized”?

Question

How do you know if you "Test Fixture" is right-sized. And by "Test Fixture" I mean a class with a bunch of tests in it.

One thing that I've always noticed with my test fixtures is that they get to be kind of verbose; seeing as they could also be not verbose enough, how do you get a sense of when your unit tests are the right size?

My assumption is that (at least in the context of web development) you should have one test fixture class per page.

I know of a good quote for this and it's:

"Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove." - Antoine de Saint-Exupery.

Answer 1

This is more to your question I think:

The metric that I use is "Test until you are comfortable" (not sure of the source). I test until I am comfortable that my code is right. If you have doubts, you probably don't have enough tests. If you feel like you are wasting your time, you should probably stop.

Re-reading, I think the following does not answer your question:

Going by this definition of Test Fixture as the setup functions, objects and mock objects that are required to make the System Under Test function: When I write tests, there is usually code that get replicated, I typically refactor that code and hide it in a region (C#). I try to keep my tests in the 5-10 line range, so if there is code that exceeds this or obfuscates the meaning of the test, I put in the fixture region. I typically don't worry about too much about fixture size. I worry more about making sure I have enough tests and that my functionality is tested.

Answer 2

Although not a hard rule, if you have detailed requirements or users stories, one test per requirement/story can be a good place to start. With that said, user stories usually don't cover all the situations that can/could go wrong so you will want to then add those scenario's geared towards assessing whether or not your component/layer behaves in a deterministic manner in exception conditions.

In school we learn to do bounds testing, range testing, etc... This is great if you have time, but in many shops things are just too busy, so building tests around the requirements allow you to at least determine if you have met the business requirements. Unit Testing from a security perspective has very different concerns so you will likely have to take other approaches and measuring what is enough will be a bit harder.