Ayende @ Rahien

Robz commented on Assert.True is the tool of last resort

Fri, 04 Sep 2009 17:18:25 GMT

@Jusin: It's the difference between TEST FAILED and [bob] is not equal to [bob.] I never have to run the debugger. I just go back to my code or test and make the fix. Illustrated from your comments I would say you don't do much automated testing where people like me live in them.

Fabio Maulo commented on Assert.True is the tool of last resort

Sat, 15 Aug 2009 00:04:17 GMT

That is the reason because I have re-wrote all messages of MsTests in Sharp Tests Ex

Ayende Rahien commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 21:33:13 GMT

Justin, If you know what the values are, you usually have a LOT more information about the error. In addition to that, many testing frameworks do things like string diffs which are _really_ helpful

Tim Wilde commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 17:35:49 GMT

@ Justin Case, I'll agree with you that if all you use the unit tests for is traffic lights indicating whether the code works or not, then yes the extra asserts are overkill. However, if you want to use the unit tests as developer documentation, it's nice to have something that is as readable and descriptive as possible which take as little parsing as possible and the extra assert variants help there.

Justin Chase commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 15:02:51 GMT

The error message from Assert.AreEqual is pointless. Oh great now you know it the failing test was because some value wasn't equal to another? So what. You're going to have to go to that test, and debug it to find out WHY the assert failed anyway. The only valuable part of a failing assert is the stack trace and the red light. If you have the file and line number of the test that's all you need. Having a million different Assert.ThisAndThat's is not wrist friendly and is extra maintenance just to get some extra information that is worthless.

Tim Wilde commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 13:50:47 GMT

*sigh* Expect is generic... Oren's blog at my generic type!

Tim Wilde commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 13:44:08 GMT

I quite like the NUnit fluent stuff with a bit of extension method sugar ( [http://code.google.com/p/nunit-extmethods/](http://code.google.com/p/nunit-extmethods/)) thrown in for readability. From Assert.Equal( "Baz", pet.Owner ); To: Assert.That( pet.Owner.Equals( "Baz" ) ); To: pet.Owner.Should( Be.EqualTo( "Baz" ) ); @Jeremy Likness, build yourself a helper method for that stuff :) I use: Expect something ); [http://codepaste.net/ngxb72](http://codepaste.net/ngxb72)>

Jeremy Likness commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 13:19:57 GMT

I've always thought this "felt" like a hack, but what would a cleaner method be? bool handled; try { something; } catch (ExpectedException) { handled = true; } Assert.IsTrue(handled, "The exception was not properly handled."); What is the "appropriate" way to test the exception handling stack?

Thomas Eyde commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 13:19:48 GMT

The last resort arrives faster in MSTest :-(

Mr_Simple commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 13:14:05 GMT

I agree, however a simple change will tell you exactly what the issue is. Assert.True(pet.Owner == "Baz", "pet.Owner == Baz");

Erik van Brakel commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 13:04:20 GMT

@Stephen A higher job title doesn't mean they're better than you with every technique ;-) Maybe those seniors come from a time unit testing wasn't so hot as it is now. Anyway, the correct reaction would be to ask the seniors what they think about it, if they're professionals they'll either say they missed it (doubtful :P) or learn from it and pick it up next time.

Stephen Harrison commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 11:18:08 GMT

During my day job at a large software house I recently came across some fresh code that contained forty Assert.True(foo.Equals(bar)) assertions (as well as a few Assert.IsNotNull) in a single test. The test fixture contained even more! Yes 40! Yes all of them in one test! Yes none of the 40 Assert.True’s had any messages in them (neither did any of the Assert.IsNotNull tests that were also in the same test). Yes the code was reviewed by one of the senior developers (actually both developers have a high job title than me). I wanted to cry, or stick pins in my eyes or something. I think this was a case of the developer being new to NUnit/unit testing so I try to suggest better ways of doing the tests when I can.

Fabian Schmied commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 09:27:47 GMT

Assert.That (pet.Owner, Is.EqualTo ("Baz")) :)

Peter Morris commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 09:08:23 GMT

Yeah, not nice :-) I used to hate seeing this if (completed == true) but at least that was just personal taste :-)

Alexey Romanov commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 07:30:43 GMT

What do you think about this approach: [themechanicalbride.blogspot.com/.../...rt-for.html](http://themechanicalbride.blogspot.com/2009/06/better-unit-tests-with-testassert-for.html) ?

Dmitry commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 00:59:48 GMT

Sometimes you might want to test the == operator implementation instead of the Equals() method.

gegen commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 00:47:19 GMT

Diego Mijelshon commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 00:38:46 GMT

I saw that in a previous job, thankfully I convinced them to fix it. There is, however, a legitimate use of Assert.True: Assert.True(theObject.IsValid) seems cleaner than: Assert.AreEqual(true, theObject.IsValid) Of course it's a matter of taste.

John Rayner commented on Assert.True is the tool of last resort

Fri, 14 Aug 2009 00:28:33 GMT

I agree the code you present is nasty, but there's an interesting technique at [themechanicalbride.blogspot.com/.../...rt-for.html](http://themechanicalbride.blogspot.com/2009/06/better-unit-tests-with-testassert-for.html). Your code looks like: TestResult.Assert( () => "Baz" == pet.Owner ); The difference is that this translates (at runtime) into: Assert.AreEqual( "Baz", pet.Owner, "pet.Owner = 'Baz'" ); IOW it presents the Lambda expression as the assertion failure message.

RobK commented on Assert.True is the tool of last resort

Thu, 13 Aug 2009 23:58:14 GMT

@Neil - Oh, it did. Was very very junior at the time and was learning TDD through examples that THE senior dev had worked up. Learned many lessons with that one.

Andrew Davey commented on Assert.True is the tool of last resort

Thu, 13 Aug 2009 23:43:47 GMT

What you really want is a macro (if using boo or nemerle) that takes the boolean expression and produces a nice descriptive message.

Damien Guard commented on Assert.True is the tool of last resort

Thu, 13 Aug 2009 23:41:46 GMT

Just this week I found myself using Assert.True when I really wanted Assert.Contains... [)amien

Neil Mosafi commented on Assert.True is the tool of last resort

Thu, 13 Aug 2009 23:39:57 GMT

@RobK hmm, surely seeing Expected 'True', Was 'False' is going to trigger the developer's "surely there's a better way" instinct?

RobK commented on Assert.True is the tool of last resort

Thu, 13 Aug 2009 23:35:43 GMT

Gotta chalk that one up to naivete (probably), and probably RTM. I remember the first time I saw the output from a failing test that was written with the appropriate Assert methods. Game changing.

Neil Mosafi commented on Assert.True is the tool of last resort

Thu, 13 Aug 2009 23:26:32 GMT

Oh that's nasty. At least put a message if you're gonna do that!