just how reflective is Objective-C

[Travis Griggs]

Here's the deal. Couple weeks ago, I finished by little GSUnit test kit. And 
we're beginning to use it in production now. Unfortunately, it doesn't have 
very good feedback mechanisms; yet. The problem manifests itself with a test 
that make look somthing like:

[self assert: [self something]];
[self assert: [self else]];
[self doSomeWork];
[self assert: [self moreAssumptions]];

As it is right now, if something fails, I'll learn that, but not _which_ one of 
the three was the failure. I've written my own macro based C test kit before. 
I've played with CPPTestKit. I've looked at JUnit. One of the strategies seems 
to be that that you support a larger set of assert: methods, such as 
assert:equals:, and then have those print out what was compared, and what the 
real value was. You can also try to use C Preprocessor defines (@LINE, etc) and 
make your assert a macro (rather than a method) which builds the information 
and dispatches to an information baggaged version of assert. I guess what I'm 
looking for here, is tricks and ideas in how to do this.

I come from the Smalltalk world, where when he have an assertion failure, we just click 
the "debug" button, and it pops us right up to the source and spot the assert 
failed. Would it be possible to invoke DDD/gdb at the point of failure?

--
Travis Griggs
Key Technology
One Man's Pink Plane is Another Man's Blue Plane