SUnit style correction

Hello all,

For some time, I have been running new tests programmatically vs. using
the SUnitBrowser.  New tests are likely to fail, so a Do-it is much
quicker than hunting for a specific test method in the browser, hitting
the run selected button, and then hitting a couple of things to enter
the debugger.  None of this takes away from the browser; it's great when
tests should pass or to find the ones that fail.

Now for the correction.  I have used

    SomeTestCase new testSomething

which bypasses #setUp and #tearDown.  Using

    SomeTestCase run:#testSomething

seems to do the job correctly.  If there are any problems with that,
please let me know.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Still not right =:0  This seems to work:

     ( SomeTestCase selector:#testSomething ) runCase.


Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill:

I also think that using the test GUI is kinda painful, especially if
you want to test a single class, and then test a whole bunch of
classes.  I normally test the heck out of the class I'm changing, and
then when it's finished, I test ALL other tests that could possibly be
broken by my changes.

It really seems painful when you've done what I've done, which is load
a bunch of goodies, that included lots of tests, ESPECIALLY some tests
that are designed to fail.

This means that if you press RUN ALL, you end up ALWAYS getting the red
screen,and have to browse the reported errors.  And if you don't press
RUN ALL, you have to scroll around, finding and clicking on every
particular test you want to run.

What I ended up doing was adding an "appOrCategory" variable to the
test cases, and altering the GUI to show this field.

That way, all of the tests that belong to a selected "appOrCategory"
could be run as a single bunch.

This way, if my application is, say a time keeping app, all of the
tests with "Time Keeping" in the appOrCategory variable can be tested
with a single click, and I don't have to worry about running tests for
objects that I haven't messed with.

Of course, before I'm completely done, I run EVERY test for EVERY
thing, since I do manage to screw up things across application
boundaries quite a bit ;)




Brody

Brody,

> I also think that using the test GUI is kinda painful, especially if
> you want to test a single class, and then test a whole bunch of
> classes.  I normally test the heck out of the class I'm changing, and
> then when it's finished, I test ALL other tests that could possibly be
> broken by my changes.

Just to clarify, I think the SUnit Browser GUI is great, but I find it
painful to use when I "know" I just broke something - that's when I want
to be able to just get on with the debugging, and do-its are the way to go.


> What I ended up doing was adding an "appOrCategory" variable to the
> test cases, and altering the GUI to show this field.
>
> That way, all of the tests that belong to a selected "appOrCategory"
> could be run as a single bunch.

Nice!


Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

> Just to clarify, I think the SUnit Browser GUI is great


I couldn't agree more.  The entire framework is just too cool.

But for the scenario you described, your idea makes a lot of sense, and
I'm  starting to use your method when I'm actively changing a class,
and know that I'm breaking stuff.

Hello all,

>>Just to clarify, I think the SUnit Browser GUI is great
>
> I couldn't agree more.  The entire framework is just too cool.
>
> But for the scenario you described, your idea makes a lot of sense, and
> I'm  starting to use your method when I'm actively changing a class,
> and know that I'm breaking stuff.

Given that my goal is to get walkbacks if there is a problem, and to
evaluate silently if all is well, I have finally added a method to
(hopefully<g>) achieve that behavior.  As it was, I was getting confused
between #run and #runCase, and had to keep testing to see which is the
preferred selector :(

If you try this and find that it deviates from the plan, please let me
know.  Sorry for the confusion.

Have a good one,

Bill



!TestCase class methodsFor!

prod:aSymbol
        "Run the test; do nothing if ok or go to a walkback."

        #wksSafe.
        ( self selector:aSymbol ) runCase.
! !
!TestCase class categoriesFor: #prod:!public! !


--
Wilhelm K. Schwab, Ph.D.
[hidden email]