On 15/08/06, Collin Winter <collinw@xxxxxxxxx> wrote:
On 8/15/06, Fergal Daly <fergal@xxxxxxxxxxxx> wrote:
> I'm actualy talking about TestSuite objects. Here's some Python
>
[snip example]
>
> So the structure is like this:
>
> all_suites
> suite1
> ATest
> testFooBar
> testOther
> AnotherTest
> testBuz
> suite2
> ...
> SomeOtherTest
> ...
>
> TAP cannot represent this nested structure.
FWIW, I've never come across a situation using unittest where knowing
the structure would be important (though I can imagine such cases).
The cases I've seen have all been along the lines of "I need to
collect all the tests in my test suite, so I'll pull all tests from my
test modules into a suite (or suite-of-suites)". In my experience, the
more important hierarchical information is of the form
$module_name.$test_case_name.$test_method_name, which TAP can handle.
What has your experience been?
Where this becomes more important is when you start constructing
suites automatically. For example
class SomeTest(unittest.TestCase):
def __init__(self, data):
self.data = data
unittest.TestCase.__init__(self)
def test_foo(self):
# some tests on self.data
def test_bar(self):
# some tests on self.data
list_of_data = [ ... ]
suite = unittest.TestSuite()
for data in list_of_data:
suite.addTest( SomeTest(data) )
suite.run()
now my suite looks like
suite
SomeTest
SomeTest
...
SomeTest
line numbers are no good to me. I haven't ever done this in Python but
I've done the equivalent in Perl. Basically as soon as you want to
have tests that are driven by data sets rather than tests that are all
explicitly written you need structure. It's also necessary for code
reuse.
Finally, it's very nice to see a GUI version where you can expand and
collapse bits of the test tree,
F
|
