Open Radar

 
Summary:
I would like Xcode to treat the corresponding unit test file for the selected class as a counterpart.


Steps to Reproduce:
1. Select a .m file, which we will call Foo.m
2. Use the Navigate > Jump to Next Counterpart in Assistant Editor menu item (you may need to hold down the Option ⌥ key for it to become visible).
3. Repeat #2.


Expected Results:
At step #2, it will select Foo.h. Then, at step #3, I would like it to select the unit test file corresponding to the Foo class.


Actual Results:
It selects Foo.h, but does not proceed on the next invocation to select the unit test file(s).


Regression:
N/A


Notes:
I use a simple pattern for my unit tests: for a class named Foo, the unit test class is named FooTests and lives in FooTests.m. I do not have a corresponding FooTests.h unless I wish to subclass FooTests for some reason (perhaps testing concrete subclasses of an abstract class). Other users may use FooTest.h/m, so it would probably be wise to support both.

In the event of a user having both .h and .m files for their unit test class (as is the default with the templates in Xcode 4), it should include both of them in the counterparts list. I would suggest that the order be: class implementation, class header, unit test implementation, unit test header. (Subtracting whichever is in the primary editor, obviously.)

If the unit test files are selected, then the class files should still be in the counterparts list.

I like to have all my tests in $(SRCROOT)/Tests, but this may vary widely. I would be willing to relocate the test class beside the original class if it would make this feature more reliable.

As a workaround, you can select a file manually in the assistant editor; however, there is no quick-and-easy shortcut for this, and you have to manage it yourself; it isn’t updated when you select another class file in the primary editor.

As another (untested) workaround, assuming you set up a build rule to treat .test files as though they were .m files, you could make the test file be Foo.test and place it alongside Foo.h/m; this is, however, invalid for aesthetic reasons. One should not have to jump through this kind of weird hoop :)

Having my unit tests right beside the class implementation is a great reminder to test, and having the unit tests in the primary editor while the class itself is in the assistant editor is a great way to do test-driven development.