test cases for unit testing

Question

In my project I have seen that we have a mass of methods that test something. If you want to understand what goes on you should look throw all methods. When you have a class with 20 test methods it's challenging for you to find test case/cases in this mass of methods.

I have never seen using interfaces for defining test cases what you cover in you tests.

For example

   puclic class A{
     public SomeResult doSomething(Param param){
       .....
      }
     ..... some other methods
   }

For this method there are 4 cases (for example);

1. check that method works as expected with null param
2. check that method throws runtime exception for some param's area
3. check that method returns expected result(normal case)
4. check something different

In our project for testing those cases , guys just create 4 method (they can be written on any order like 2 first cases present at the beginning of test class and the last second can be written at the end (200 lines of code below)). Also from the test's name is not always clear what test method checks.

Is it good way to describe the test cases in a interface in this way :

public interface ATestSpecification{
    void doSomething_checkForNullParam();
    void doSomething_checkExceptionForNotAllowedParam();
    void doSomething_normalCase();
    void doSomething_checkSomethingDifferent();
}

And the test class :

public class ATest implement ATestSpecification{
...
//implenent test cases , described in test specification
...
}

Answer 1

Since developer tests are essentially documentation and exist for the convenience of the developer(s) working on the code, I would recommend that you do away with that idea of creating interfaces for test methods--have never seen that before and am sorry to have seen it just now. The existence of those interfaces can only get in your way when you search the code for references to a method name or have your IDE display a call hierarchy on any method that you would want to find an example of how to use correctly. Don't put things in your own way.

In the case of tests, because they are documentation, I tend to diverge from the usual pattern for naming methods in Java. That is, I will abandon using camelCase in favor of all_lowercase_separated_by_underscores, which seems easier to read, generally. Thus I will have "should_do_something" or "ensure_whatever" so that the test case name helps me find what I might be looking for. Also, I would be less focused on testing methods and more focused on testing behavior--I know that sounds like splitting hairs, but that's the way I think of it. Figure out what the class needs to do and write those tests then implement using TDD. I usually don't feel the need to back-fill any tests if I use TDD or a close approximation thereof. Jimmy is completely correct about keeping your code focused and following SRP.

Hope that helps!

EDIT: naming conventions are always controversial--just pick one that works for you. it's come up here and here before.