List Info

Thread: Shared TestCase object for each test method




Shared TestCase object for each test method
user name
2008-02-12 13:31:48
Hi, I just ran across some interesting behavior that I
didn't see
documented anywhere. SimpleTest, being a "clone"
of JUnit, doesn't
follow JUnit's implementation in creating a new TestCase
object for
each test method, thus the constructor is only called once.

This actually worked out as a benefit for me because I
needed to do
some per-class initialization in my test case. Overriding
setUp()
caused the initialization to be performed multiple times,
once for
each test method. I'm curious, is this behavior by design?
Or is it an
implementation detail that is subject to change and should
not be
relied upon? If it's the former, perhaps it would be helpful
to
mention it somewhere in the documentation.

Btw, I love how you guys incorporated mock objects testing.
The more I
use SimpleTest, the more I like it. Thanks for a great piece
of
software.

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

Re: Shared TestCase object for each test method
country flaguser name
United States
2008-02-12 14:45:16
Daed Lee wrote:
> Hi, I just ran across some interesting behavior that I
didn't see
> documented anywhere. SimpleTest, being a
"clone" of JUnit, doesn't
> follow JUnit's implementation in creating a new
TestCase object for
> each test method, thus the constructor is only called
once.

Is this really the case? Curious!

> This actually worked out as a benefit for me because I
needed to do
> some per-class initialization in my test case.
Overriding setUp()
> caused the initialization to be performed multiple
times, once for
> each test method. I'm curious, is this behavior by
design? Or is it an
> implementation detail that is subject to change and
should not be
> relied upon? If it's the former, perhaps it would be
helpful to
> mention it somewhere in the documentation.

No, it's perfectly correct: setUp() is called before each
test method
(tearDown() is called after each test method), and
__construct() is only
called once. However, you shouldn't rely on the constructor
being called
immediately before the test.

-- 
 Edward Z. Yang                        GnuPG: 0x869C48DA
 HTML Purifier <http://htmlpurifier.org&g
t; Anti-XSS Filter
 [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

Re: Shared TestCase object for each test method
user name
2008-02-12 15:07:52
> > Hi, I just ran across some interesting behavior
that I didn't see
> > documented anywhere. SimpleTest, being a
"clone" of JUnit, doesn't
> > follow JUnit's implementation in creating a new
TestCase object for
> > each test method, thus the constructor is only
called once.
>
> Is this really the case? Curious!

Yup, that's how JUnit does it. See here for details:
h
ttp://martinfowler.com/bliki/JunitNewInstance.html

> > This actually worked out as a benefit for me
because I needed to do
> > some per-class initialization in my test case.
Overriding setUp()
> > caused the initialization to be performed multiple
times, once for
> > each test method. I'm curious, is this behavior by
design? Or is it an
> > implementation detail that is subject to change
and should not be
> > relied upon? If it's the former, perhaps it would
be helpful to
> > mention it somewhere in the documentation.
>
> No, it's perfectly correct: setUp() is called before
each test method
> (tearDown() is called after each test method), and
__construct() is only
> called once.

I agree, nothing wrong with this implementation. I actually
prefer it
due to the use case I mentioned, but it might be surprising
for some
coming from a JUnit background. Hence, I think it's worth
mentioning
this implementation detail in the documentation.

> However, you shouldn't rely on the constructor being
called
> immediately before the test.

True, although I don't alter any state set up in the
constructor when
running the test methods so this is not an issue for me.

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

Re: Shared TestCase object for each test method
user name
2008-02-12 15:46:31
Hi...

Daed Lee wrote:
> I'm curious, is this behavior by design? Or is it an
> implementation detail that is subject to change and
should not be
> relied upon?

It's by design. JUnit has just a few too many surprises for
the 
newcomer and this is one. In fact it used to be a FAQ on the
website.

There are pros and cons of each. A single test case is more
natural, 
and SimpleTest is designed with newcomers in mind. In favour
of 
separate test cases, it means that there is less cross talk
between 
tests. As PHP is riddled with stuff that can cause cross
talk 
anyway, I kinda' figured that this was less important.

Different unit testers do different things. NUnit builds the
test 
case just once, although I think they now regret this choice
due to 
incompatibility with JUnit.

If you use the TestSuite::addFile() method (and autorun),
SimpleTest 
will construct the test case just before it's used. It will
destroy 
it immediately afterwoods (before moving to the next test
case).

This is guaranteed.

yours, Marcus

p.s. Yes the docs seriously need updating .

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

Re: Shared TestCase object for each test method
country flaguser name
United States
2008-02-12 16:12:46
Howdy all...

On Feb 12, 2008, at 3:46 PM, Marcus Baker wrote:

> Daed Lee wrote:
>> I'm curious, is this behavior by design? Or is it
an
>> implementation detail that is subject to change and
should not be
>> relied upon?
>
> It's by design. JUnit has just a few too many surprises
for the
> newcomer and this is one. In fact it used to be a FAQ
on the website.
>
> There are pros and cons of each. A single test case is
more natural,
> and SimpleTest is designed with newcomers in mind. In
favour of
> separate test cases, it means that there is less cross
talk between
> tests. As PHP is riddled with stuff that can cause
cross talk
> anyway, I kinda' figured that this was less important.
>
> Different unit testers do different things. NUnit
builds the test
> case just once, although I think they now regret this
choice due to
> incompatibility with JUnit.

Interesting that this came up.  I've been meaning to address
it here  
on the list.

I'm sort of in favor of moving toward the JUnit style, or at
least  
allowing a test case class to specify that it wants to be  
instantiated for each test.  Seems like BC could be
preserved while  
still allowing people to separate out each test if they so
desired by  
making instancePerRun() or some such method return true.  My
mind is  
going to running tests in parallel and such where having
each test  
method as highly focused as possible allows that much finer
control  
for parallel execution.

-T

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

Re: Shared TestCase object for each test method
user name
2008-02-12 16:19:35
Thanks for your reply Marcus. I have a lot more faith in my
tests
knowing this implementation detail is by design.

On the subject of documentation, I just wanted to point out
a couple
of issues you might want to fix when you get around to
updating the
documentation:

On the http://simpletest.org/en/mock_objects_documentation.html
 page,
in the "Mocks as critics" section, there's a code
snippet that's
formatted incorrectly.

On the h
ttp://simpletest.org/en/gain_control_tutorial.html page,
there
are duplicate links in the left navigation bar.

Hopefully, I'll be able to contribute with some code in the
future.
Digest authentication is something that might be useful for
a future
project of mine.


On Feb 12, 2008 4:46 PM, Marcus Baker <marcuswordtracker.com> wrote:
> Hi...
>
> Daed Lee wrote:
> > I'm curious, is this behavior by design? Or is it
an
> > implementation detail that is subject to change
and should not be
> > relied upon?
>
> It's by design. JUnit has just a few too many surprises
for the
> newcomer and this is one. In fact it used to be a FAQ
on the website.
>
> There are pros and cons of each. A single test case is
more natural,
> and SimpleTest is designed with newcomers in mind. In
favour of
> separate test cases, it means that there is less cross
talk between
> tests. As PHP is riddled with stuff that can cause
cross talk
> anyway, I kinda' figured that this was less important.
>
> Different unit testers do different things. NUnit
builds the test
> case just once, although I think they now regret this
choice due to
> incompatibility with JUnit.
>
> If you use the TestSuite::addFile() method (and
autorun), SimpleTest
> will construct the test case just before it's used. It
will destroy
> it immediately afterwoods (before moving to the next
test case).
>
> This is guaranteed.
>
> yours, Marcus
>
> p.s. Yes the docs seriously need updating .
>
>
>
------------------------------------------------------------
-------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Simpletest-support mailing list
> Simpletest-supportlists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simp
letest-support
>

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

Re: Shared TestCase object for each test method
user name
2008-02-12 16:35:15
Parellel execution is interesting, although a simpler method
to
achieve that might be to just move the tests into separate
classes
rather than changing the unit of encapsulation from a class
to a
method. The former just seems much more natural.


On Feb 12, 2008 5:12 PM, Travis Swicegood
<developmentdomain51.com> wrote:
> Howdy all...
>
> On Feb 12, 2008, at 3:46 PM, Marcus Baker wrote:
>
> > Daed Lee wrote:
> >> I'm curious, is this behavior by design? Or is
it an
> >> implementation detail that is subject to
change and should not be
> >> relied upon?
> >
> > It's by design. JUnit has just a few too many
surprises for the
> > newcomer and this is one. In fact it used to be a
FAQ on the website.
> >
> > There are pros and cons of each. A single test
case is more natural,
> > and SimpleTest is designed with newcomers in mind.
In favour of
> > separate test cases, it means that there is less
cross talk between
> > tests. As PHP is riddled with stuff that can cause
cross talk
> > anyway, I kinda' figured that this was less
important.
> >
> > Different unit testers do different things. NUnit
builds the test
> > case just once, although I think they now regret
this choice due to
> > incompatibility with JUnit.
>
> Interesting that this came up.  I've been meaning to
address it here
> on the list.
>
> I'm sort of in favor of moving toward the JUnit style,
or at least
> allowing a test case class to specify that it wants to
be
> instantiated for each test.  Seems like BC could be
preserved while
> still allowing people to separate out each test if they
so desired by
> making instancePerRun() or some such method return
true.  My mind is
> going to running tests in parallel and such where
having each test
> method as highly focused as possible allows that much
finer control
> for parallel execution.
>
> -T
>
>
>
------------------------------------------------------------
-------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Simpletest-support mailing list
> Simpletest-supportlists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simp
letest-support
>

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Simpletest-support mailing list
Simpletest-supportlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simp
letest-support

[1-7]

about | contact  Other archives ( Real Estate discussion Medical topics )