Writing tests in single file or writing each test in a separate file? I have found few advantages of keeping test cases in separate file.

  1. Easy to maintain, better readability, easy to run single test.
  2. There can be 80 to 100 lines of code for every test case including comments. Say if we write 10 tests in a single file then there will be ~1000 lines of code which will be very hard to manage. Typically we will have more than 10 tests in a functionality. On the other hand if we have it as single file we can easily identify tests from the file name itself.
  • @KilianFoth In my case it is not specifically for unit testing
    – Karthick
    Commented Dec 5, 2013 at 11:24

2 Answers 2


At first, the question looks superfluous. For a decently sized product, no one would even think of writing all tests in a single file of course.

When it comes to functional/performance/integration/etc tests, these are usually involved to set up and already quite large by their nature, such that separation is again the obvious choice.

There is, however, the case of unit tests where we do have advantages when keeping tests in a single file:

  • If the test file grows too large, it is an indication that your tested unit/class is too large as well. So what is a downside for other tests becomes a useful warning signal for unit tests.
  • You have exactly all relevant tests for the respective unit together. Other tests, like integration tests, tend to encompass multiple system components, which means it is inherently difficult to identify all parts. For unit tests, there is always just that one unit, and it wouldn't make much sense to have to find multiple test files for it.
  • Continuous testing: While you can theoretically run your whole test suite each time you save your source file, this is infeasible due to the long runtime of some more involved tests. Unit tests on the other hand are supposed to execute blazingly fast and having all tests for your unit in one file, you can edit away mercilessly whilst having the guarantee that on every save the complete unit is tested. This is possible in theory with split files as well, but practically, the CT tools assume one unit - one test.

The last reason above is sufficient for me personally to warrant not splitting unit tests. Especially with IDEs you get support for things like moving between unit and test code via a simple shortcut key, or in other words: there is absolutely no effort needed to find/execute/do anything with the relevant test code of your unit. Something which is simply no longer possible on tests that encompass multiple units.

So in summary, I'd argue that your given advantages are really only present for non-unit tests. When considering unit tests, quite the opposite holds true: having them in one file means they are easy to maintain and run, and as explained above, excessive size is useful as a code smell detector in that case.

  • Actually here we planned to do non-unit test. So keeping every in separate file will make sense right? And let say in some emergency cases if I want to execute specific test case alone then I can easily pass my specific test case files to my test executor. In the above situation if I have all the cases in a single file then all the cases will get executed so there we need to wait all the test cases to complete. So I am going to keep my test cases in separate file. :)
    – Karthick
    Commented Dec 5, 2013 at 11:33

General guideline is to mimic the code files. For example,

If we have two class files:

  • Employee
  • Department

We should create test files like below:

  • EmployeeTest
  • DepartmentTest

Naming the test file based on the code file with 'Test' suffix is also a guideline. These guidelines make tests easy to structure/discover eg in a large project you don't have to tell a developer/tester where to find the test for a particular feature, it is intuitive.

However, it is just a guideline and not a rule.

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