0

I have a test class with about 25 tests that are testing the different aspect of it.

I wonder

  • Should I break it down into smaller classes?
  • If so, then what is the best naming/packaging convention?

Lets say my class name is abcService and I want to break it down into x, y and z aspect of it.

  1. Name test classes as xTest, yTest and zTest. The problem with this way is, it might be hard for someone else to find tests for the abcService class as it have different name and usually people look for abcServiceTest file.
  2. Create folder in test section and name it abcServiceTest and move xTest, yTest and zTest into it.
  3. Name test classes as abcServiceTestForX, abcServiceTestForY and abcServiceTestForZ
2

The unit test file has a direct correlation to the code file it is testing. So, the underlying problem is most likely with code itself. If you refactor the code that is under test into smaller classes with single responsibilities, then the unit test file(s) will be smaller as well and then will be no need to create multiple test file with some sort of naming schema/convention.

25 tests is not that bad. If many tests are just variations on a theme, consider creating one test that is data driven from a list of data in the test itself or external in a file.

| improve this answer | |
0

Jon Raynor's answer is not wrong, but it's not a hard and fast rule either. It's perfectly within reason to separate your unit test classes into classes for each method if you'd prefer it to be. Especially for methods with a high variability in outcomes, it can enhance readability to separate these tests.

In such a case, your multiple test classes will generally want to inherit from the same ancestor which sets up your test object. It cuts down on some boilerplating.

  1. Name test classes as xTest, yTest and zTest

  2. Name test classes as abcServiceTestForX, abcServiceTestForY and abcServiceTestForZ

I use option 3 for this, it's the most readable in my opinion.

I would suggest a more descriptive name, such as abcService_GetFoo, abcService_GetBar (assuming those are the methods), ... this makes it easy for you to see what each class tests.

I generally split on different methods, but your mileage may vary.

  1. Create folder in test section and name it abcServiceTest and move xTest, yTest and zTest into it.

Regardless of naming, I would suggest always putting the multiple test classes (which test the same type) in the same folder which marks the name of the type being tested. something along the lines of \abcService\abcService_GetFoo.cs, \abcService\abcService_GetBar.cs.

Whether you repeat the abcService class name in the test classes is open to debate, it varies from developer to developer. My current team is actually split on this (2 devs on either side).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.