< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous (in thread)
N :the next (in thread)
|<:the top of this thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
On 2002.05.21, Bob Hutchison <hutch / recursive.ca> wrote:
> I don't know if I'd like to give up the organisation of multiple test
> files, and I don't know if I'd like to have to organise and navigate
> through a single file of 2500 lines.
This was my initial negative reaction to Dave's otherwise
excellent idea.
Right now, tests are organized at a higher level as test
suites. Dave's way, while great for the "simple testing" couples
tests with classes, not by test suites.
In other words: how would I run a subset of tests that were
coupled to a class? How could I have N of the tests use one
setup/teardown while the other M tests use a different or none
at all?
There might be some core tests that want to live directly
inside the class, but then maybe those really ought to be
assertions that are actually part of the class's code itself,
not as a test that only gets run conditionally. I'm not
100% convinced of this, but ... it's a thought.
I definitely think having RDoc be Test::Unit-literate would
be cool. Pass RDoc over my unit tests and have it extract
test cases and their conditions (the "message" passed to
the assert_* methods maybe) ... but then, after all this,
isn't it simply easier to just pretty-print your test
cases as-is and let the reader do the intelligent work?
-- Dossy
--
Dossy Shiobara mail: dossy / panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)