Re: Unit testing and Xcode integration
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