0

I'm new to xcode and objective-c. I also decided to add unit (logic) tests to my project. The tests work fine (using OCUnit and SenTestingKit). What I don't understand is how the build for testing works. Let me explain..

I write a simple unit test that checks for an empty array - uses 

STAssertTrue([array count] ==0, @"Should have an empty array, but it is not");

This builds fine and the test passes.

Now if I change it from 0 to 1, the build fails. It doesn't make sense to me why the build fails - there is nothing incorrect with the code. It seems to me that the build is actually running the code and the assert is asserting.

How can one step through the code to determine the problem in the method if the method was to return an array with one element? It is obvious in this simple example as to the problem, but if the method to be tested has more depth to it, one needs to step through it to correct the problem. Running unit tests like this does not seem to be very easy to work with - unless there is something I'm completely missing.

My question is: how to step through a unit test that fails?

suspectus
  • 16,548
  • 8
  • 49
  • 57
Mike Weber
  • 311
  • 2
  • 16
  • Can you please state the steps you took more explicitly? I'm not clear what the problem is. It seems like you're saying that your build fails if your unit tests fail? That shouldn't be the case, and I just verified that it's not in my own project. – Dov Jun 08 '12 at 18:15
  • It is possible that I have something set incorrectly and hoping to find help solving it here. The problem is if unit tests are working fine and building successfully, why would the build fail if something simple is changed as in STAssertEqual (x == 2); // where is x is 3. It should still build without issue and the developer should be able to step through the code and see why x is 3 and fix the issue, but that is not the case. So when there is more complex code, the build fails and it is not possible to execute and step through the code. Am I doing something wrong? Are my expectations off? – Mike Weber Jun 10 '12 at 04:24
  • It would probably be helpful for you to post a sample project that someone else can open, or else provide specific instructions for someone else to be able to easily recreate a demo project. – Dov Jun 10 '12 at 13:17
  • Here is a link to the zipped project https://www.dropbox.com/sh/9efnu5ba877cp7l/woH1svNog4 – Mike Weber Jun 11 '12 at 20:18
  • Thanks, but you might want to take that down. Do you want the whole internet looking at all your source code? In any event, it would be even more helpful for you and me if you created a new project from scratch demonstrating your problem. That said, I noticed you have the setting "Test After Build" turned on for your project. Could that be the problem? If so, I'll update my answer. – Dov Jun 12 '12 at 00:08
  • That did it. And this was going to be throw away code - there is/was nothing special about it. Thanks for downloading and looking at the project. That setting was one I didn't notice. Once unit tests are working and in place, then it would be safe for me to set this back to "Test After Build" as code is refactored. – Mike Weber Jun 13 '12 at 01:29

1 Answers1

1

You need to turn off the Test After Build setting in your project if you don't want broken tests to cause a build failure. If in the future your build is failing because of your tests, you can debug your test cases by executing them (Product -> Test) and setting breakpoints, the same as you would debug any other code. This wasn't always the case with Xcode, but it is with 4.3, as you stated you're using.

You also ask what "Build for Testing" means. This question covers the same ground: Xcode 4 terms "Build for testing / Build for running / build for profiling / build for archiving"

Community
  • 1
  • 1
Dov
  • 15,530
  • 13
  • 76
  • 177
  • Setting breakpoints does not help - the code is not being executed, therefore the breakpoint will not be hit. If it builds, I can run the tests and hit breakpoints. – Mike Weber Jun 10 '12 at 04:18
  • Answer updated to reflect conclusion arrived at in the comments. – Dov Jun 13 '12 at 02:26