• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Unit testing and Xcode integration
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unit testing and Xcode integration


  • Subject: Re: Unit testing and Xcode integration
  • From: Greg Hurrell <email@hidden>
  • Date: Wed, 16 Aug 2006 04:30:30 +0200

El 16/08/2006, a las 4:04, Nir Soffer escribió:
I actually prefer that behaviour. If my code has 100 failing tests in it I want to know about all of them, not just the first one. But I suppose OCUnit could be modified to optionally throw an exception on failing a test, and to abort when such an exception occurs.

After a test fails, your other tests (within the same test method) may not be valid any more. For example:


STAssertNotNil(obj);
STAssertEqualObjects([obj name], @"Foo"]);

With your preferred behavior, when obj is nil, you will get two failures, but the second failure is bogus. obj may be correct, but you test code failed to obtain the instance, or the object responsible to return the instance failed. This pattern is quite common in my tests.

In cases where one piece of code depends on an earlier one and the earlier one might fail I use assertions (not "test assertions", but normal assertions). So in other words...


foo = [bar doSomething];
NSAssert(foo != nil, @"foo was nil!");
[foo doSomethingElse];

Or in a form that might be more familiar:

void *buffer = malloc(bufferSize);
NSAssert(buffer != NULL, @"malloc failure");
[MyClass doSomethingWith:buffer];

I carry that same pattern across to my unit tests. If I have something that depends on something else earlier on being true and there is a possibility of failure, I assert. Whatever tests I might put in there don't displace that pattern, they get laid over the top of it. So to modify my first example above:

foo = [bar doSomething];
NSAssert(foo != nil, @"foo was nil!");
[foo doSomethingElse];
STAssertEqualObjects(foo, @"bar");

I understand it's a question of personal style, but that's the way I do things. In the case above, if foo is nil then the assertion raises an exception, indicating to me that my code is broken and I need to fix it or the test won't even be executed. I have one assertion and one test in there instead of two tests because in that way the code is closer to what it would be in production use, and I'm really testing what I expect my code to do rather than minutely inspecting it at every step of the way. I guess I mean it brings the testing methodology closer to Behaviour Driven Development, which in my view is a good thing.

http://blog.daveastels.com/articles/2005/07/05/a-new-look-at-test- driven-development

http://behaviour-driven.org/

G




_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Unit testing and Xcode integration (From: "Christian Moen" <email@hidden>)
 >Re: Unit testing and Xcode integration (From: Chris Hanson <email@hidden>)
 >Re: Re: Unit testing and Xcode integration (From: "Christian Moen" <email@hidden>)
 >Re: Unit testing and Xcode integration (From: Chris Hanson <email@hidden>)
 >Re: Re: Unit testing and Xcode integration (From: "Christian Moen" <email@hidden>)
 >Re: Unit testing and Xcode integration (From: Chris Hanson <email@hidden>)
 >Re: Unit testing and Xcode integration (From: Nir Soffer <email@hidden>)
 >Re: Unit testing and Xcode integration (From: Greg Hurrell <email@hidden>)
 >Re: Unit testing and Xcode integration (From: Nir Soffer <email@hidden>)

  • Prev by Date: Re: Cocoa binding and threads.
  • Next by Date: Newbie Question on Style
  • Previous by thread: Re: Unit testing and Xcode integration
  • Next by thread: Re: Unit testing and Xcode integration
  • Index(es):
    • Date
    • Thread