Unit Testing

Hi,

        I'm beggining to use Unit Tests to test the parts of my software.

        I want to know if there exists any test about "Unit Testing" (in
general) besides the Kent Beck's paper, when I say "in general", I
mean "how to build/design" the tests. A kind of guideline.

        Thanks.

--
Esteban.

Esteban,

the basics is pretty simple. Here is one sample for start. For more
sophisticated tests look into the subclasses of TestCase for examples.

I use as ann example the Team Class from the Ted's Book, the Dolphin
Smlltalk Companion, you can see the basic tests in a workspace on p.
30:
team1 := Team new.
team 1 inspect
team1 name: 'Ferrari'
...

So the SUnit steps could be:
1. Check you have classes beginning with SUnit in the CHB. (or the
SUnitBrowser in the Tools/Additional Tools)
2. Create a new class with TestCase as super class with the name
CH3TeamTest. A good place is your your Application package. Add team1
as instance variable
3. Create a method with the name setUp for setting up the test
environment like:
setUp
        "setting up the Team for Unittest"
        team1 := Team new.

4.) Create a mthod with the name teaDown to clean up after test. I use:
tearDown
        "setting team1 to nil after the test run, which filled the instance
variables"
        team1 := nil.

5. Create methods with syntax prefix 'test' for testing different
aspects, for ex: testTeamName etc...

testTeamName
        "a silly testing example: if the TeamName is 'Ferrari' after setting
it on the page 30 of the Dolphin Smalltalk Companion."
        team1 name: 'Ferrari'.
        self assert: ( team1 name = 'Ferrari').

6. Now Open SUnit Browser, where you should see CH3TeamTest. select it,
run it with the red triangle.

If you would like a failing test, insert

        self assert: ( team1 name = 'Ferrario')

as a last line in the testTeamName.

some useful inherited methods are: should: shouldnot: and so on, you
find them in the TestCase class.

Good luck,
Janos

Hi Janos,

Janos Kazsoki escribió:
> Esteban,
> the basics is pretty simple. Here is one sample for start. For more
> sophisticated tests look into the subclasses of TestCase for examples.

        Thanks for your answer, i've made some tests, even some more
complicated for some presenters i've built, testing with the SUnit
SASE extensions for DolphinXP.

        What I'm looking for is not in "how to implement" (code), i'm
looking "what to test".
        Extremme Programming books and papers are plenty of examples, but
many of them trivial as setting the name to an object, or checking
whether evaluation 3+4 answers 7 (which may be useful if you're
building a smalltalk VM :-) ). Too many buzzwording also.

        Perhaps a "good" XP book, has other examples, as how to set DB for
testing (Gold, Silver DB, etc.).

        The Kent Beck's original paper, gives "the pattern" for how to
test. Object-Arts SASE testing adds additional "implementation
details".
        I don't want to do TDD (I don't like it), but want to find a good
guideline on what to test, testing everything doesn't seem
appropiate to me (I can be wrong, of course).
        Something like "Become a software tester in 24 hours, days, or
months" ;-)

        Best regards.

--
Esteban.

Esteban,

> What I'm looking for is not in "how to implement" (code), i'm
> looking "what to test".   Extremme Programming books and papers are
> plenty of examples, but many of them trivial as setting the name to
> an object, or checking whether evaluation 3+4 answers 7 (which may be
> useful if you're building a smalltalk VM :-) ). Too many buzzwording
> also.

We're planning to ship the Pro version of D6 with our own unit tests,
so that might give you some ideas.

<snip>
> I don't want to do TDD (I don't like it),
<snip>

When you see how well the D6 auto-completion works when programming in
the debugger (because of the extra contextual information available)
then you *might* change your mind. :-)

Best regards

Andy Bower
Dolphin Support
www.object-arts.com

Andy Bower escribió:
> Esteban,

>>What I'm looking for is not in "how to implement" (code),
 >>i'm looking "what to test".<snip>

> We're planning to ship the Pro version of D6 with our own unit tests,
> so that might give you some ideas.

The wait is getting more interesting every week. :-)

>>I don't want to do TDD (I don't like it),
> When you see how well the D6 auto-completion works when programming in
> the debugger (because of the extra contextual information available)
> then you *might* change your mind. :-)

I tend to develop on the debugger without auto-completion, so I'll
have to wait D6 to see how it behaves. But not doing TDD. Perhaps
I'm at one step of it.

Best regards, and free D6 soon!!! :-D

--
Esteban.

> Best regards, and free D6 soon!!! :-D

Is a free version of D6 meant to be public knowledge? :)

Sean M wrote:

>Is a free version of D6 meant to be public knowledge? :)
>  
>
Would be nice, but I assume free as in "let out, release to the (paying)
world..."

Esteban,

>     I don't want to do TDD (I don't like it), but want to find a good
> guideline on what to test, testing everything doesn't seem appropiate to
> me (I can be wrong, of course).
>     Something like "Become a software tester in 24 hours, days, or
> months" ;-)

With respect to TDD, I think it depends on the problem.  Some things are
very well suited to it, and it makes a lot of sense to write the tests
as a way to start the debugger (tongue only partly in cheek).

What to test?  IMHO, test systems and their entry points.  Hopefully
that will exercise the intermediate code w/o your having to write tests
that will only get refactored into oblivion.  My favorite sources of
tests are "I know the answer" and "this should not have happened".  The
former condition gets me starting thinking about TDD, and the latter is
stuff that I (and sadly sometimes my users) find while working with
software.

Something that might help you: I routinely put a comment such as

    "
       SomeTestCase new testSomething
    "

in each test method.  When I first write the test, the thing will break,
and a do-it allows me to go pretty much directly into the debugger with
the context of the test.  When there reasonable expectation that lots of
things will pass, then the SU browser is the way to go.  When I lock in
on something that is broken, the do-it again provides direct access to
the debugger.

Have a good one,

Bill

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

Andy Bower wrote:

> When you see how well the D6 auto-completion works when programming in
> the debugger (because of the extra contextual information available)
> then you *might* change your mind. :-)

Music to my ears. Like a lot of people around here, I imagine, I write
Java for a living while wishing I could get back to writing Smalltalk
for a living.

It's not heaven, but one thing I *love* about writing Java in Eclipse is
the brilliant auto-completion - and that's something I've been sorely
missing while writing Smalltalk lately.

> Andy Bower



                           Steve

Mark Derricutt escribió:
> Sean M wrote:
>
>> Is a free version of D6 meant to be public knowledge? :)  
>>
> Would be nice, but I assume free as in "let out, release to the (paying)
> world..."

Yes... I tried to say that.

Free = Release.

Best regards

--
Esteban.

> Yes... I tried to say that.
>
> Free = Release.

Thanks for clearing that up :)