[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
just how reflective is Objective-C
From: |
Travis Griggs |
Subject: |
just how reflective is Objective-C |
Date: |
Tue, 20 May 2003 11:04:01 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- just how reflective is Objective-C,
Travis Griggs <=