Open Radar

 
24-Oct-2009 09:42 AM Dave Dribin:
Unit test targets are just a code bundle, and cannot be executed directly.  When built, there's a Run Script build phase that actually runs the tests.  A typical setup is to have the unit test bundle dependent on the target being tested.  Thus by by simply building the unit test target with Command-B, it builds the dependent target, then the tests, and finally the tests are run.

This has a couple of drawbacks:

1) It's hard to debug the unit tests, since there's no executable to debug
2) Unit tests are run on every build: success, fail, or up-to-date

#1 is covered in <rdar://problem/7215100>.  #2 is an issue because the tests are run in two often undesirable cases: when the dependent target fails due to compile errors and when the targets are up-to-date.

When tests are run even though the dependent target fails, the unit tests running just get in the way.  At best, they run successfully, on the previous successful build of the dependent target.  This is can be annoying  if the unit tests take a while to run, though.  But if the previous run of the tests failed for some reason, the unit tests fail on top of the compile errors, and get in the way of the compile errors you are trying to fix.

Tests are also run even if all targets are up to date.  This is often the case when you use Command-R repeatedly to run the main application.  For these cases, I'd rather not run the unit tests.  They ran (and succeeded) when the targets were first built, so there's no need to run them every time I hit Command-R.  Again, this can be particularly annoying if the unit tests take a while to run.

Removing the Run Script phase and using an executable instead would solve this.  Then *I* could decide if I wanted to run the unit tests vs. not by changing the active executable and choosing between Command-B and Command-R.  This would also help improve the debugging situation since I could now just use Command-Y to debug the unit test executable.