SUnit and inherited tests

---

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

Travis Griggs wrote:
I used this feautre only *once*, but in that case it did paid off.
I have an abstract TestCase superclass which itself has 15 tests
methods and a bunch of support methods some of which are abstract.
This class has 5 concrete subclasses. But this style has its drawbacks:
   * First, the tests were quite difficult to extrapolate so the code
     is not so straightforward (easily readable by newcomer) as it would
     be without using this feature.
   * Second, when I was debugging the tests, I saw for example 38 errors
     in the red bar but when I clicked on "Show defects", I saw just few
     of them. And it took me quite some time to figure this out.

And when this feature will not be available, there is still a way
for those who need it:
     AbstractTest>>test_method
       "some asserts"

     ConcreteTest>>test_method
       "subclass of AbstractTest"
       super test_method

This is a bit more work, but introduce no code duplication and works
great with tools...

So all and all I think I could quite easily live without this feature
if it helps enhance the framework.

Ladislav Lenart

I have used that a few times. Mostly it follows the pattern that I want to test that some things work regardless of the way a particular option is set.

For example, in Glorp there is an option to try to use joins to implement an anySatisfy:, or use a subselect with an EXISTS test. This can affect performance, depending on the database, but shouldn't affect semantics. So there are a group of tests, and a subclass.

In WebToolkit there are a number of tests that exercise sending requests through various gateways. So we have an abstract superclass that sends requests to a web server and examines the results to make sure they're what's expected. Where to send the requests to, both in terms of server/port and of possible URL prefixes, is parameterized. Subclasses change these parameters, so if you run the tiny http tests you connect directly to the server, and if you run the ISAPI Gateway tests you connect via IIS and use the ISAPI gateway. And if you just run all the tests in the package, you do all of them.

This seems like a useful mechanism, although it does make it more awkward to browse/modify the tests. I kind of like the idea of automatically being in browse superclass mode when looking at such a test, though it might have some other "principle of most astonishment" implications.

At 07:44 PM 8/31/2006, Travis Griggs wrote:

I've been playing with the notion of adding other means of specifying "this is a test" information to testMethods (namely pragmas and protocols). One thing that makes it more complex, is the notions of "abstract test classes" and "should inherit selectors." When I did SUnitToo, I just ported this stuff directly from SUnit. I didn't give it too much thought.

It seems prudent to reconsider it at this point. My problem is that I don't do this kind of thing usually (abstract test frameworks). I think it's part a tools issue. To show an "inherited" test status in the browser, you'd have to always be in "show superclass methods" mode. Plus I like to keep my TestClasses testMethods pretty mundane, even to the point of violating "once and only once". So I'm seeking some input.

Who does use these features. If you were starting from scratch, what would be the "simplest thing that could possibly work", not the end all uber powerful solution, just the simple thing that would cover the common case.

One way of solving the tools issue maybe, is to cause the browser to automagically enter "show inherited methods" when it detects that it is a TestCase with abstract tests in the super. Have to think about that.

--
Travis Griggs
Objologist
"It had better be a pretty good meeting, to be better than no meeting
at all" - Boyd K Packer



DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

From: [hidden email]

To: [hidden email]

Sent: Thursday, August 31, 2006 6:44 PM

Subject: SUnit and inherited tests

I've been playing with the notion of adding other means of specifying "this is a test" information to testMethods (namely pragmas and protocols). One thing that makes it more complex, is the notions of "abstract test classes" and "should inherit selectors." When I did SUnitToo, I just ported this stuff directly from SUnit. I didn't give it too much thought.

It seems prudent to reconsider it at this point. My problem is that I don't do this kind of thing usually (abstract test frameworks). I think it's part a tools issue. To show an "inherited" test status in the browser, you'd have to always be in "show superclass methods" mode. Plus I like to keep my TestClasses testMethods pretty mundane, even to the point of violating "once and only once". So I'm seeking some input.

Who does use these features. If you were starting from scratch, what would be the "simplest thing that could possibly work", not the end all uber powerful solution, just the simple thing that would cover the common case.

One way of solving the tools issue maybe, is to cause the browser to automagically enter "show inherited methods" when it detects that it is a TestCase with abstract tests in the super. Have to think about that.

--

Travis Griggs

Objologist

"It had better be a pretty good meeting, to be better than no meeting

at all" - Boyd K Packer

---

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

Travis,

>Who does use these features.

Well, first off, it's not per se about abstract superclass, although it can be.

For instance, in Pollock, we have 4 Looks. I start off with a set of tests for,
say a Button, and the Win9x look, and a Resource to set the Look to Win9x for
that test.

What I then did, is make a subclass of that test class, called MotifButtonTests,
and had it inherit all the tests, and give IT a Resource to set the Look to
Motif. Then, all I have to do is override, in MotifButtonTests those methods
where the test would be different. Such as testing what the Artist is for the
Button.

So, the inheritance of tests is very useful... The tests that are the same no
matter what, should (and do) pass and the ones that are specific to the Look
subclass test, are different.

If I were someone who was creating Smalltalk from scratch, I might create a Test
for say, SequencableCollection, and then subclass that test for subclasses of
SequencableCollection, making sure than that the same basic tests pass for all
subclasses.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

> Who does use these features.

I wrote couple of vector and matrix implementations, about three  
dozens, and have one test with subclasses for the different  
implementations.

For the UI I'd suggest to introduce "ad-hoc methods" like the dynamic  
protocols RB extension by Karsten does for protocols, and these ad-
hoc methods are shown, text grayed out, when I am NOT in view  
superclass methods, just as a placeholder to show the status icon.

Grüsse,
        Adrian K.