My favorites | Sign in
Project Home Downloads Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 1: Setup and teardown question
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  AnodyneP...@gmail.com
Closed:  Dec 2007


 
Project Member Reported by AnodyneP...@gmail.com, Jun 6, 2007
Should the setup and teardown methods be run around each test method, or
just  once for the entire test class?  

The reason I ask is that we might need to do that to provide some stability
in the tests.  I had adopted a strategy of using the setup method to create
an instance of the object under review with appropriate values set for all
of the properties.

Then, in my tests for accesor functions I just compared against the values
I had set in the setup method.  For mutators, I would set a new and
different value in the property and then immediately compare it with itself.

The problem I ran into is when the mutator test function executed before
the accessor test function.  It would change the value in the object that
was set up before it could be tested.

It's not that big of a problem, I'll just have to write my tests a little
different, but it is something we should probably make people aware of.

I know Marc was talking about running a single test method and this might
come into play there as well.


Jun 6, 2007
Project Member #1 AnodyneP...@gmail.com
One other note.  The tests are not run by the runtestremote method either
alphabetically or in the order they appear in the test cfc, although they do seem to
be presented consistently.  I'm guessing this has something to do with the way cf
works with structures.
Jun 9, 2007
Project Member #2 virtix
Good question. On first read, I think we should make sure it behaves as does JUnit. 
When I look at MXUnit tests, there is one call to setUp() and tearDown() for each 
test case. It makes sense that the runTests should follow this. This brings up an 
interesting question, too, with respect to fixtures. If a test alters the state of 
an object and another test depends upon that object, what should the responsibility 
of the test be with respect to the state of the object? Should it reset it back to 
its state just before the test was called. What if another test is dependent upon 
the altered state of the object? Maybe this is not good test practice? This also 
touches on the order thing ...

Anyway, I say we look at the Junit design and, for now, make it behave that way. 


Dec 14, 2007
Project Member #3 virtix
Finally resolved this. Marc fixed it so that setup/teardown is called for each test
method
Status: Fixed

Powered by Google Project Hosting