Comments on: Assertions: actual or expected first? http://grahamis.com/blog/2009/06/05/assertions_actual_or_expected_first/ It's too real to be true Sat, 07 May 2011 05:40:39 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Srushti http://grahamis.com/blog/2009/06/05/assertions_actual_or_expected_first/comment-page-1/#comment-435 Srushti Sat, 06 Jun 2009 06:39:19 +0000 http://grahamis.com/blog/2009/06/05/assertions_actual_or_expected_first/#comment-435 On my last project (.net) I created extension methods for assertions as a wrapper around NUnit assertions. public static void ShouldBe(this T actual, T expected); The assertions would then read x.ShouldBe(20). You can also extend this by adding other methods for other assertions: public static void ShouldBeTrue(this bool actual); public static void ShouldBeAtLeast(this int actual, int expected); ...and so on. On my last project (.net) I created extension methods for assertions as a wrapper around NUnit assertions.

public static void ShouldBe(this T actual, T expected);

The assertions would then read x.ShouldBe(20).

You can also extend this by adding other methods for other assertions:

public static void ShouldBeTrue(this bool actual);

public static void ShouldBeAtLeast(this int actual, int expected);

…and so on.

]]> By: Nick Drew http://grahamis.com/blog/2009/06/05/assertions_actual_or_expected_first/comment-page-1/#comment-434 Nick Drew Sat, 06 Jun 2009 03:28:06 +0000 http://grahamis.com/blog/2009/06/05/assertions_actual_or_expected_first/#comment-434 So in (rspec originated) BDD we have should matcher In hamcrest we have assertthat( actual, matcher ) In old Junit we have Assert( expected, actual ) In mstest we have a mix of Assert( actual, expected ) and CollectionsAssert.Contains( actual, element ) All pretty inconsistent. I have to say that I may I find it easier to maintain complex assertions with the matcher syntax. For complex document traversals, I may start of with: assertThat( document, hasXPath( "//book[@title='" + expected_title + "'] )) but after writing too many very similar xpath expressions, I may find myself with the following: assertThat( document, hasBook( hasTitle( expected_title ), hasAuthor( expected_author ) ) I find that evolution very powerful, and I find it more convenient to keep the actual values lined up on the left side while the equivalence classes/matchers fluctutate on the right hand side. So in (rspec originated) BDD we have should matcher
In hamcrest we have assertthat( actual, matcher )
In old Junit we have Assert( expected, actual )
In mstest we have a mix of Assert( actual, expected ) and CollectionsAssert.Contains( actual, element )

All pretty inconsistent.

I have to say that I may I find it easier to maintain complex assertions with the matcher syntax.
For complex document traversals, I may start of with:

assertThat( document, hasXPath( “//book[@title='" + expected_title + "'] ))

but after writing too many very similar xpath expressions, I may find myself with the following:

assertThat( document, hasBook( hasTitle( expected_title ), hasAuthor( expected_author ) )

I find that evolution very powerful, and I find it more convenient to keep the actual values lined up on the left side while the equivalence classes/matchers fluctutate on the right hand side.

]]>