CODEWITHSUNDEEP
java
yegor256
yegor256

Reputation: 105073

How to organize unit tests for a complex class?

I have a complex class (300+ lines), which I'm trying to test from different "points of view". I've already created three different unit tests. Every test is a complex class itself (100+ lines). The question is -- what is the best place to store them, in project directory tree? This is how I'm doing it now (Maven is used):

pom.xml
/src
  /main
    /java
      /com
        /Foo
          ComplexClass.java
  /test
    /java
      /com
        /Foo
          /ComplexClass
            FirstPointOfViewTest.java
            SecondPointOfViewTest.java
            ThirdPointOfViewTest.java

Of course, the names are just placeholders, used in order to explain the problem/question. What do you think about this approach?

Upvotes: 4

Views: 1786

Answers (3)

Philipp Jardas
Philipp Jardas

Reputation: 3302

Your class is so complex that you need three different test classes to test all the aspect of the class? Probably you have mixed too many concerns in a single class. I would suggest refactoring the class using proven design patterns to separate classes with orthogonal concerns that can then be tested individually.

Upvotes: 6

Jon Freedman
Jon Freedman

Reputation: 9697

I'd keep what you currently have. The main advantage of this maven structure is that rather than mixing source and test code together and trying to identify which classes to exclude from your build you just ignore the test directory entirely. The point of using the same package is to expose protected methods/variables to your test classes but not to a public API.

One thing I might suggest is something I picked up at a talk by John Smart on Test Driven Development which is to name your test classes in groups of functionality they are testing, so you just have FirstPointOfView.java which is testing the behaviour of your first point of view of the com.foo package. This approach should make it more obvious when you can split a test class into individual classes, if they are actually testing different sets of behaviour.

Edit: if ComplexClass is a directory you should drop that, so that your tests are in the same package, I think I may have missread your example tree

Upvotes: 0

Tom Tresansky
Tom Tresansky

Reputation: 19892

One thing you might want to consider: if you keep your test code package structure the same as your main code package structure---even using different physical directories as you are currently doing---your test classes will be in the same logical package as your main classes. This means they gain access to default/protected members in the tested classes, which is often helpful. You'd have to get rid of the ComplexClass package in the test code to make that happen.

Another thing to consider: (I'll assuming you're testing with JUnit) Test classes are classes, so you can organize and structure them using inheritance. If you have 3 different points of view, maybe extract a base class which contains common functionality, this will make your tests easier to maintain in the long run, especially as more "points of view" are discovered.

Separating the source and test code as you are already doing is a great idea, it gives you more options for building and maintains a logical grouping which makes maintenance more straightforward.

Upvotes: 3

Related Questions