Understanding SUnit mindset from JUnit background

Its been years since I've used Smalltalk and coming back to it from Java and
.Net has been fun but at times a bit confusing and frustrating.

One thing I am really grappling with is TDD (test driven development) in
Smalltalk. I know it originated from Smalltalk but way back then I was
transitioning to java when I heard about it. Not having an up to date
Smalltalker to pair with, I'm hoping someone can help me understand the flow
of TDD in ST.

for me its working a bit frustratingly as follows:

1.  I subclass TestCase.
2.  I begin writing a new testXXXX method (I give it a good name - in Java
TestDox can generate some documentation for me - haven't see that in ST, but
its trivial. I do note that the SUnit test runner can "english-ify" the test
name if you select the right option)

3. I implement some expected behavior, and think about what I want to assert
as follows:

testShouldHandleLeapYears
....
result := myModel processFoo: (Date fromString: '1/1/1975').

self assert: result = -1.

4. I recall Andy giving a demo of Dolphin years ago - and he ran the test,
and in the debugger picked "implementIn" for #processFoo: That seems to work
pretty well most of the time (and is slightly better than Java - although
Idea and Eclipse now both offer to implemement the method when you've typed
it in). I also enter a return value like "nil" to make sure my test breaks
properly.

5. This is the bit that I struggle with. Having entered an incorrect return
value, my SUnit browser doesn't seem very helpful as compared to Java. It
shows the red bar, but I have to click on the TestSuite to see which tests
fail, and then all I see are X's next to the failing tests - No obvious
indication of why they fail? In java - junit shows me a summary of the
failure next to each test. A few times now, I've just figured a failure is a
failure and retured to my test to fix it - however I've been burned a few
times now, fixing the wrong problem.

So in SUnit - I've tried hovering over each test (nothing), clicking on it
(nothing in the status line). So it seems like what people must do is -
click on a failing test and click the "debug button". Now I get a walback
window - but its taken quite a few clicks to get here.

6. Having a walkback window, I now have to figure out what the error is -
there's nothing useful in the title, and the default walkback shows nothing
particularly obvious

7. I click on debug, the variable panel (top right) looks promising but only
shows: aString "assertion failed". If I click down the stack trace, I notice
my testXXXX, select it and can now see which assertion was failing. Still to
see which value my "result" was, I still have to do inspect to understand I
got "nil" instead of -1.

This seems very long winded - so I wonder if I'm missing an obvious trick?
SUnit is pretty established so I wonder if like in Step 4 (implmentIn) I am
missing an obvious trick?

To me (java hat on) it seems like the following is missing:

1. Why is there no #assertEquals:with: method that shows the actual and
expected values?
        e.g.
         ^self assert: expectedObject = anObject
              description: 'Expected: ', expectedObject printString, ' But
was: ', anObject printString
                    , (aString isEmpty ifTrue: [''] ifFalse: [' (' , aString
, ')'])

    At least this way - in step 6, the debugger title is useful

2. The SUnit browser should automatically select the first failed test, and
have an error pane that shows the "message" part of an exception

3. Dolphin should have an "Accelerator" to automatically run the Suni
browser with a single keystroke.

Those 3 things are what the Java IDE's have (which seem applicable to ST?) -
but again I stress that maybe I've not got the right mindset and am missing
a different way of using the environment. Can anyone offer any tips - before
I go off and start creating lots of work for myself.

Tim

TimM wrote:

> 4. I recall Andy giving a demo of Dolphin years ago - and he ran the test,
> and in the debugger picked "implementIn" for #processFoo: That seems to work
> pretty well most of the time (and is slightly better than Java - although
> Idea and Eclipse now both offer to implemement the method when you've typed
> it in).

This is different. What IDEA and Eclipse lets you do is to generate the
method stub while you are creating the unit test. In Dolphin (and other
Smalltalks), you would run the unit test and get a DNU and then you can
proceed to implement the method while being able to inspect the
parameters and instance variables, etc and then continue running the
test.

> So in SUnit - I've tried hovering over each test (nothing), clicking on it
> (nothing in the status line). So it seems like what people must do is -
> click on a failing test and click the "debug button". Now I get a walback
> window - but its taken quite a few clicks to get here.

That's what I do too.

> 1. Why is there no #assertEquals:with: method that shows the actual and
> expected values?

You just showed it :) Its #assert:description:.

> 3. Dolphin should have an "Accelerator" to automatically run the Suni
> browser with a single keystroke.

My guess is everyone who has thought of stuff like this ended up
implementing this in their own customisation package with their own
quirks, so you don't see much of a demand for this :) Mine's:

========
bindings := ClassBrowserShell acceleratorKeyBindings.
bindings at: 'Ctrl+0' put: #runCurrentClassAsUnitTest.
ClassBrowserShell acceleratorKeyBindings: bindings.


ClassBrowserShell>> runCurrentClassAsUnitTest
  self selectedClass isUnitTest ifFalse: [^self].
  classesPresenter runTests.
  self setFocus

Object class>>isUnitTest
  ^false

TestCase class>>isUnitTest
  ^true
========


Oh, and welcome back :)

HweeBoon