Re: How do I debug break in case of assertion failure?

I'm not discounting that you may need to go into the debugger in such a
situation, but I can't imagine that
it would be useful for /every/ assertion to cause a break.
 
I'm also not sure how breaking after the assertion failure is useful. When I
(rarely) use the debugger,
I generally want to step into the call, not break after the failure. 
 
Maybe it would help if you described what you woud do if you found yourself
in the debugger, at the
point in Assert.That where an exception is about to be thrown. What would
you want to do next?
 
Charlie
 



  _____  

From: [email protected]
[mailto:[email protected]] On Behalf Of Igor Gatis
Sent: Thursday, August 07, 2008 1:50 PM
To: Simone Busoli; [email protected]
Subject: Re: [Nunit-users] How do I debug break in case of assertion
failure?


The assertion it self is a simple condition. Consider this:

bool result = Server.DoSomething(param1, param2, complexParam1,
complexParam2);
Assert.IsTrue(result);

The assertion will say false, expected true. Right?

Assume this is the first time I'm writing tests for this Server interface.
It would be nice "to be notified" what exactly caused result to be false.
You can quickly do that by inspecting parameters values on a debugger.

Anyways... sorry for this long discussion. Maybe NUnit is just not what I'm
looking for. Maybe just a single Class with some utility methods would do
the job.




On Thu, Aug 7, 2008 at 12:42 PM, Simone Busoli <[email protected]>
wrote:



Let's say a test case failed. Don't you want to know what the state was
right there? 



The assertion is there to tell you right that.
 



On Thu, Aug 7, 2008 at 12:34 PM, Laimonas Simutis <[email protected]> wrote:


Not sure how others feel about this, but I find the behavior of NUnit
Assert call having something to do with debugger very very "weird".
Aren't the two completely unrelated concepts? It seems to me that this
behavior would be needed if the code was not written with testing
first, but instead already existed and now the tests are being written
for it. You end up debugging the test flow because you are not sure
what fails where.

I would say adding this feature would just encourage bad
behavior/practice in unit testing...


On Thu, Aug 7, 2008 at 2:27 PM, Charlie Poole
<[email protected]> wrote:
> Hi Igor,
>
> I believe people is just used to the behavior of
> System.Diagnostics.Debug.Assert(). Besides, while developing tests, it
helps
> a lot to have a automatic break mechanism; in case of failure, the test
> developer can easily check values and verify what is going on. With such
> mechanism in place, the following steps are collapsed in a single one:
>
> 1) Run tests for the first time
> 2) Verify where exactly the failure was
> 3) Open a debugger
> 4) Place a break point
> 5) Run tests again
>
> While using NUnit, I was expecting to find something like:
>
> Assert.BreakOnFailure = true;
>
> It's default value would be false. Once I'm done with development of the
> tests, I could just remove or comment out this line.
> IMHO, In the way you're saying, you're pushing NUnit users to write tests
in
> a specific way, which is fine. That the adoption a little less attractive
> though.
>
> First of all, I like your suggestion. Would you submit a feature request?
>
> But on the last part, I should clarify a bit. Mainstream Microsoft users
are
> relative late-comers to NUnit.  So, while NUnit may seem to push those
folks
> in odd directions, they are the directions that the developers and early
> adopters expected it to push.
>
> Those early adopters were not primarily MS users, but were folks familiar
> with this style of testing in other platforms. NUnit (and testing) was
> pretty well ignored by the community around MS for many years, so folks in
> that community have not had a lot of input into what NUnit does. As more
> "mainstream" folks start to use NUnit, there's a need to balance between
> it's original goals and their expectations. We will probably never add any
> features that members of that original community would consider a bad
> practice. OTOH - and your suggestion may be a case in point - we could add
> things that those folks consider as merely unnecessary.
>
> Unfortunately, though making such a feature available will likely mean
that
> those folks will never learn how unnecessary the debugger really is most
of
> the time. That's too bad, but it's probably inevitable.
>
> Charlie
>

> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100
<http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/
> _______________________________________________
> Nunit-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nunit-users
>
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100
<http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/
_______________________________________________
Nunit-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-users




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100
<http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/
_______________________________________________
Nunit-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-users

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Nunit-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-users