Managing code: Unit tests with source or separate

testingxcode

The standard practice in the Objective C world has been to follow that laid down in the Java world when it comes to code management. i.e. Your application source code goes in one directory, and your unit test code goes in another.

I've always found this a bit of a pain. Especially as I tend to organise XCode the same way. The issues that annoy me are:

Having to keep all the various groups in sync in terms of naming, etc.
Not easily being able to see which classes have matching test classes.
Having to scroll up and down through hierarchies all the time as I'm bouncing between tests and source.

So I've been thinking – What if I put the test code beside the source code? In the same directory. And in XCode I can then have the test code sitting with the source and easily locate and see the matching classes.

Has anyone tried this? Is it workable? Or is there another solution?

Best Answer

As Uncle Bob always says, your tests should not be coupled to the structure of your application (great blog discussing this topic).

Doing what you're suggesting sounds like you may run into issues with deployment, or other aspects of development... But the biggest issue I see is you'll be tempted to (if not forced to) couple your test-suite tot your application structure.

I wouldn't recommend allowing yourself to deal with the world of future headaches (from something simple such as a small package refactor) that come with this decision.

Related Solutions

Unit-testing – How should I test the TEST code

The standard flow for TDD is:

Write a failing test. (Red)
Make the smallest code change that makes it pass (Green)
Refactor (Keeping it green)

The test for your tests in this case is step 1 - making sure that the test fails before you make any code changes.

Another test that I like is whether you can delete some code and re-implement it a different way, and your tests fail after deletion but work with a different algorithm in place.

As with all things, there is no magic bullet. Forgetting to write a required test is just as easy for a developer to do as forgetting to write the code. At least if you're doing both, you have twice as many opportunities to discover your omission.

Unit-testing – Unit Tests code duplication

Declare class TestArith as abstract. Then create two classes, TestIntegerArith and TestDoubleArith extending TestArith. In the TestArith create an abstract method getArithmetic, which returns an instance of Arithmetic. Then change the tests to get Arithmetic instance by calling getArithmetic.

So it would look like this:

public abstract class TestArith<T> {
  protected abstract Arithmetic<T> getArithmetic();

  @Test
  public void testAdd() {
      assertEquals(7, getArithmetic().add(term1, term2));
  }
}

Best Answer

Related Solutions

Unit-testing – How should I test the TEST code

Unit-testing – Unit Tests code duplication

Related Topic