After Assert.PASS or Assert.Fail code is not executed, Problem or Feature ?
Milan_Milan
If accepted to have such division in 1, 2, 3 steps there will be
another things to discuss, like:
a. Implementing some local [SetUpLocal] and local [TearDownLocal] with
validity only inside one [Test] space/method.
b. Implemented (better say pulling it out from some other place where
they are already called) ResetTimer(), StopTimer(); function for
measuring elapsed time but now just for the step "2". So execution of
step "1" and "3" is not real elapsed time for that test method so step
"2" should be embraced with explicit call of function e.g.
Assert.ResetTimer() at the beginning of method "2" and after step/
block "2" ends Assert.StopTimer().
Br,
Milan.
====================================================
Milan said on 2009-12-11:
Ok Charlie,
lets finished here this question and I will next time ask at nunit-
discuss list (in case we can not find easy answer I will copy this to
nunit-discuss list).
For example, for testing some library working with Data Base, there is
a lot of functions each needed clean-up in sense of delete everything
unit-test did on the tested table. For every table I make couple of
tests and after every test I need to clean it so that following unit-
test start with the clean table. With 30 Tables and 5 test per table
one comes to pretty huge number of "TestFixture".
Having the same number of "TestFixture" like tested functions is too
complicated. I think that having some "small" cleanups in every unit
test should be allowed, does anything says against ?
Best regards,
Milan.
====================================================
Charlie Poole said on 2009-12-11:
Organize your tests so that step 1 is handled in a SetUp or
TestFixtureSetUp method and step 3 is handled by TearDown or
TestFixtureTearDown. In that way, you ensure that the cleanup is taken
care of even in case of a failure or unexpected exception.
If you find that some of your test methods require different setup/
teardown, then it's probably an indication that you need to put them
into a separate test fixture.
====================================================
Milan said on 2009-12-10
Hi Uniters,
at page:
http://www.nunit.org/index.php?p=assertions&r=2.5.2
is written:
"If an assertion fails, the method call does not return and an error
is reported. If a test contains multiple assertions, any that follow
the one that failed will not be executed. For this reason, it's
usually best to try for one assertion per test."
So maybe I am making conceptual thinking error but every my Unit test
case is generalized so that it consist of sequentially following
parts:
1. initialize unit test function
2. test unit function
3. deinitialize test function
in the step "2" is set Assert.Fail or Assert.Pass. After call of those
two function no code is more executed so "deinitialization/cleanup" is
not possible, right ?
Some workarounds like setting Pass Fail at end of unit test are
possible but in case when tester need to test just step "2" than
potential errors/exception which happens in the step "3" would
influence unnecessary end result.
best regards,
Milan.
Charlie Poole
For some reason I didn't get your private note, quoted below,
so I'll respond to both of them here.
It's a common feature of all the xUnit frameworks (sUnit,
jUnit, etc.) that a failure stops the test. The word
"fixture" was invented to describe the common setup and
teardown needed for a group of tests. Like most (but not
all) frameworks, NUnit represents a fixture as a class.
That means you are encouraged to put all the methods with
common setup and teardown requirements into the same class.
When people don't do this, they are working against the
natural way that NUnit works, which leads to problems. So
my suggestion is to *first* try to do it the way NUnit is
designed to work. If that doesn't do the job for you, then
it's time to think about modifications. The extra benefit
for you is that (if you can use NUnit in its natural way)
your tests will work immediately, without having to wait
for a new NUnit release. :-)
All that said, if you still need to have some small
cleanup in an individual test, the pattern to use is
try
{
// The test code
}
finally
{
// Do your cleanup
}
This is a little bit cumbersome, which IMO is a good thing
because you won't be tempted to do it often. :-)
Regarding your alternative suggestions (a & b):
a) I don't quite understand this. What would you put the
SetUpLocalAttribute on? Can you provide an example?
b) This is a separate matter and might make a good feature
request. However, you have to be aware that different people
want different results out of the test times. Many of us
just want to know how long the tests take to run. If there
is lots of setup, then the tests run slower so we may want
to fix that. You seem to be more interested in how long
a particular call takes, which is a different matter. Any
good solution has to take both needs into account.
Charlie
Charlie
>
> You received this message because you are subscribed to the
> Google Groups "NUnit-Discuss" group.
> To post to this group, send email to nunit-...@googlegroups.com.
> To unsubscribe from this group, send email to
> nunit-discus...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nunit-discuss?hl=en.
>
>
>
Milan_Milan
First point under b)
- I gave it second(fifth...) thought and it seems to be possible to
avoid need for such timers. If some part of the functions need to be
tested on duration inside one NUnit test user can use windows methods
for measuring time and at the end write them to Assert.Pass as
argument e.g:
Assert.Pass ("123.45ms");
The problem here is that I can not find where string passed as
argument to Assert.Pass is written ? I can not find it in
TestResult.xml file ?
Point under a)
the idea was that some new attribute which has the name "[SetUpLocal]"
would act as [SetUp] just at the level of every unit test method.
Proposed workaround with try-finally block could do the workaround, if
not "I'll be back" on this thread :)
Br,
Milan.
> >http://groups.google.com/group/nunit-discuss?hl=en.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -
Milan_Milan
First point under b)
- I gave it second(fifth...) thought and it seems to be possible to
avoid need for such timers. If some part of the functions need to be
tested on duration inside one NUnit test user can use windows methods
for measuring time and at the end write them to Assert.Pass as
argument e.g:
Assert.Pass ("123.45ms");
The problem here is that I can not find where string passed as
argument to Assert.Pass is written ? I can not find it in
TestResult.xml file ?
Point under a)
the idea was that some new attribute which has the name "[SetUpLocal]"
would act as [SetUp] just at the level of every unit test method.
Proposed workaround with try-finally block could do the workaround, if
not "I'll be back" on this thread :)
Br,
Milan.
On 16 Dez., 18:16, "Charlie Poole" <char...@nunit.com> wrote:
Charlie Poole
> First point under b)
> - I gave it second(fifth...) thought and it seems to be
> possible to avoid need for such timers. If some part of the
> functions need to be tested on duration inside one NUnit test
> user can use windows methods for measuring time and at the
> end write them to Assert.Pass as argument e.g:
> Assert.Pass ("123.45ms");
Yes, or write it to console if that's good enough for your needs.
> The problem here is that I can not find where string passed
> as argument to Assert.Pass is written ? I can not find it in
> TestResult.xml file ?
That's been requested but is not available yet. Currently, the
only place you can see the message is in the Test Properties
dialog of the Gui.
> Point under a)
> the idea was that some new attribute which has the name "[SetUpLocal]"
> would act as [SetUp] just at the level of every unit test method.
> Proposed workaround with try-finally block could do the
> workaround, if not "I'll be back" on this thread :)
Yes, that's the part I already understood. :-)
But an attribute has to appear be placed on something, so I'm asking
for an example showing a test method with a local setup as you
envision it. I really can't picture how this would work.
Charlie
Milan_Milan
Point under a):
- I am looking forward of getting reacher TestResult.xml with adequate
support with nunit-result, HTML reporter.
under point b) example could be:
[Test, Description("Test method")]
public void NUniteTestMethod()
{
[SetupLocalStart]
// do some local initializations valid only for this NUnit test
method
// ...
[SetupLocalEnd]
// do some test
// ...
Assert.Pass/Fail();
[TearDownLocalStart]
// do some clean up, related to only this NUnit method
// ...
[TearDownLocalEnd]
}
I am not expert in .NET programming so I am not sure that one can
simple write new Attribute(e.g. SetupLocalStart) somwhere in the
middle of code but if possible above pseudo code could do the job.
Br,
Milan.
cliff
thanks
cliff
Charlie Poole
> Point under a):
> - I am looking forward of getting reacher TestResult.xml with
> adequate support with nunit-result, HTML reporter.
The xml format needs to remain backward compatible for NUnit 2.x.
With 3.0, we'll redefine it although we may need to keep some sort
of /oldxmlformat option.
So, for any additive change that won't mess up folks who use their
own XSL to reformat TestResult.xml, you could file a request against
NUnit 2.5. But for incompatible changes, it should go against
NUnit 3.0.
> under point b) example could be:
>
> [Test, Description("Test method")]
> public void NUniteTestMethod()
> {
>
> [SetupLocalStart]
> // do some local initializations valid only for this
> NUnit test method
> // ...
>
> [SetupLocalEnd]
>
> // do some test
> // ...
>
>
> Assert.Pass/Fail();
>
>
>
> [TearDownLocalStart]
> // do some clean up, related to only this NUnit method
> // ...
>
> [TearDownLocalEnd]
>
> }
>
> I am not expert in .NET programming so I am not sure that one
> can simple write new Attribute(e.g. SetupLocalStart) somwhere
> in the middle of code but if possible above pseudo code could
> do the job.
No, it's not possible, which was the reason for my question.
Attributes have to attach to an element in the file, for example
a method or a class.
Aside from that, your example with multiple setup's and tests
matches the pattern...
Arrange
Act
Assert
Arrange
Act
Assert
which most folks consider an anti-pattern. That is, if your test
needs two stages of setup, then it is apparently testing two
different things and should be split.
Charlie
Milan_Milan
point under a):
I am not familiar with compatibility issues but if additional
parameters are written to TestResult.xml that should not disturb xml
parser in nunit-result tool right (new items are ignored normally) ?
So writting "message" text passed as argument to Assert.Pass/fail
("message") to xml file should not affect compatibility in any NUnit
version.
In what Bug/Feature is going to be handle this problem ?
point under b):
now I do not understand where do I have mention patern of two times
"Act". I have Initialization/Act/Assert/Deinitialization and that's
it, so no two stages. There is proposed two stages of setup, first
global for the whole class and than local for Unit test.
Workaround with "try-finally" would do the job too so let us
concentrate on point "a)".
Having nice test report is the only thing I can show to the my boss
and in this moment it looks pretty poor :(
Br,
Milan.
> ...
>
> read more »
Charlie Poole
> point under a):
> I am not familiar with compatibility issues but if additional
> parameters are written to TestResult.xml that should not
> disturb xml parser in nunit-result tool right (new items are
> ignored normally) ?
Yes, this is what I meant by an "additive change"
> So writting "message" text passed as argument to Assert.Pass/fail
> ("message") to xml file should not affect compatibility in
> any NUnit version.
Correct.
> In what Bug/Feature is going to be handle this problem ?
We have a feature request in Sourceforge to do this...
http://sourceforge.net/tracker/?func=detail&aid=2693430&group_id=10749&atid=
360749
Sourceforge feature requests are in the process of being moved
to our Launchpad site, so unfortunately you sometimes have to
look in both places.
I'm guessing you would like this one to be given more priority. :-)
>
> point under b):
> now I do not understand where do I have mention patern of two
> times "Act". I have
> Initialization/Act/Assert/Deinitialization and that's it, so
> no two stages. There is proposed two stages of setup, first
> global for the whole class and than local for Unit test.
> Workaround with "try-finally" would do the job too so let us
> concentrate on point "a)".
Your example appeared to show moving on to a second test in the
same method... I may have misunderstood your intent.
> Having nice test report is the only thing I can show to the
> my boss and in this moment it looks pretty poor :(
Unfortunately, NUnit can do little to help with a boss who puts
priority on the wrong things!
Charlie
Charlie Poole
> > In what Bug/Feature is going to be handle this problem ?
>
> We have a feature request in Sourceforge to do this...
> http://sourceforge.net/tracker/?func=detail&aid=2693430&group_
> id=10749&atid=360749
>
> Sourceforge feature requests are in the process of being
> moved to our Launchpad site, so unfortunately you sometimes
> have to look in both places.
>
> I'm guessing you would like this one to be given more priority. :-)
See https://bugs.launchpad.net/nunitv2/+bug/498630
Charlie
Milan_Milan
>> my boss and in this moment it looks pretty poor :(
>Unfortunately, NUnit can do little to help with a boss who puts
>priority on the wrong things!
Hi Charlie,
:-) dont say so ... he will force me to use some other unit tool...and
I do not want that :)
The really point is that having nice overview with comments for pass/
fail/... brings more information to the tester (like proposed that in
Assert.Pass message is written e.g. test duration or something else)
and that is what at the end counts.
Milan.