Re: 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&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
>>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>

-------------------------------------------------------------------------
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