FW: About SUnit

Thomas Koenig tomkoenig at mindspring.com
Sat Apr 16 02:08:32 UTC 2005


You are correct "the setup method is executed once before 'each
testMethod'" and the tear down is executed once after each testMethod.
The idea is that each testMethod of a particular TestCase share a set of
easily understood test fixtures but that each is completely independent
of each other.  setUp and tearDown are responsible for ensure exactly
that: common but independent test conditions. See Kent Beck´s original
Smalltalk testing paper:  Simple Smalltalk Testing: With Patterns
http://www.xprogramming.com/testfram.htm  for more back ground on the
idea.
If "you don't think that this is what you want to do." it may be you
want Test Resources.  Resources use the singleton pattern to ensure they
get executed only once.  The upside is they are executed only once; the
downside is that the tests must not change the resource hence they risk
compromising the independence and therefore the repeatability of the
tests. See  Joseph Pelrine's introduction to Test Resources
http://www.metaprog.ch/downloads/TestResources.pdf for a better idea on
how to use.
Also see http://minnow.cc.gatech.edu/squeak/1547  for more Squeak SUnit
links


-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of
Raymond Asselin
Sent: Friday, April 15, 2005 10:41 PM
To: squeak-dev
Subject: About SUnit


Say, you have a TestCase in SUnit with 7 testMethods and one setup
method.

It seems to me that the setup method is executed once before 'each
testMethod' and I don't think that this is what I want to do.

My question:  what is the supposed behavior of setup in SUnit ?

===

As I use POP3Client in my setup, is this possible that POP3Client does 7
'retries'  and that it is what fool me ? Because there is a 20 sec.
timeout somewhere in the code call by POP3Client. What is the relation
between timeout and retries when you use POP3Client ?

Raymond




More information about the Squeak-dev mailing list