# Thursday, 23 April 2009

I have recently started researching the mocking framework RhinoMocks and finding good resources hasn’t been as easy as I was hoping it would be.  I decided to post the useful links I found to this point.  I am hoping this will become a living post for all RhinoMocks references worth tracking.

Reader Submitted
posted on Thursday, 23 April 2009 03:39:00 (Central Daylight Time, UTC-05:00)  #    Comments [4]
# Sunday, 19 April 2009
There are a few assertions, other than Exception assertion, that are missing from MsTest.  Some of these I missed enough to roll my own are GreaterThan, GreaterThanOrEqualTo, LessThan, and LessThanOrEqualTo.  Check the code out to see how I accomplished this.

posted on Sunday, 19 April 2009 17:30:22 (Central Daylight Time, UTC-05:00)  #    Comments [2]
# Friday, 03 April 2009

Although the built in unit testing is nice, for us user’s of ReSharper it is something we have had for awhile with their NUnit integration, it is missing some things from NUnit that I have come to love, one of which is the ability to test expected exceptions.  MSTest does supply the ExpectedException attribute which does allow you to test for a single exception, helpful if all methods you code only throw a single exception each.  If your methods are more complicated you have to write a test for each of the exceptions you expect to encounter.

        /// <summary>
        ///A test for ATestMethod
        ///</summary>
        [TestMethod]
        [HostType("ASP.NET")]
        [AspNetDevelopmentServerHost("%PathToWebRoot%\\Learning\\CustomAssertions\\CustomAssertions\\CustomAssertions", "/")]
        [UrlToTest("http://localhost:1777/")]
        [ExpectedException(typeof(ArgumentNullException))]
        public void ATestMethodTest()
        {
            string s = "Test";
            int actual = MethodsForTesting.ATestMethod(s);
            //This is a valid, simple but still valid, test of the pass condition.
            Assert.AreEqual(1, actual);
            //What if I want to test the part of my code that throws exceptions?
            //The only built in solution that MsTest offers is using the "ExpectedException" attribute.
            actual = MethodsForTesting.ATestMethod(null);
            //Because you can only have one per method it leaves a little something to be desired
            //If I want to test more than one expected exception I need to have a test for each ExpectedException after the first
        }

        /// <summary>
        ///Another test for ATestMethod
        ///</summary>
        [TestMethod]
        [HostType("ASP.NET")]
        [AspNetDevelopmentServerHost("%PathToWebRoot%\\Learning\\CustomAssertions\\CustomAssertions\\CustomAssertions", "/")]
        [UrlToTest("http://localhost:1777/")]
        [ExpectedException(typeof(InvalidOperationException))]
        public void ATestMethodTest2()
        {
            //So this is the test of my second ExpectedException.
            //If you are writing one unit test per method plus one for each expected exception
            //your test suite is going to get of of control before you know it.
            string s = "This is a long string";
            int actual = MethodsForTesting.ATestMethod(s);
        }
Because creating a unit test for every exception I needed to catch is not something I wanted to do, not to mention that in my opinion using attributes doesn’t lend itself to easily read code, I decided to look into re-creating the functionality.  Using generics and delegates I was able to accomplish this without too much of a headache, other than the fact that my current contracting gig has me coding in VB and for some reason when I am coding in VB I occasionally mix in some C# and when I am coding in C# I mix in some VB…shouldn’t the IDE be smart enough to make the conversion for you?  So I can now test for expected exceptions until I am blue in the face.  Here is the above code rewritten using the AssertException class.

        /// <summary>
///A test for ATestMethod
///</summary>
[TestMethod]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost("%PathToWebRoot%\\Learning\\CustomAssertions\\CustomAssertions\\CustomAssertions", "/")]
[UrlToTest("http://localhost:1777/")]
public void ATestMethodTestWithCustomAssertException()
{
int actual = MethodsForTesting.ATestMethod("Testing");
//This is a valid, simple but still valid, test of the pass condition.
Assert.AreEqual(1, actual);
//Test of the null argument logic
AssertException.Throws<ArgumentNullException>(() => MethodsForTesting.ATestMethod(null));
//Test of the string is too long logic
AssertException.Throws<InvalidOperationException>(() => MethodsForTesting.ATestMethod("A really looooooooooooooooooooooong string."));
}

The Throws method has an override that includes the expected error message as well.  I also coded a ThrowsSoapException custom assertion that allows you to look for a specific exception message as well as a specific soap fault code.  You can download the rest of the code, including unit tests of course, here.

posted on Friday, 03 April 2009 17:51:59 (Central Standard Time, UTC-06:00)  #    Comments [9]
# Thursday, 26 March 2009

In the last week or so I have realized how much a benefit test driven development can be.  I am not going to go into the scholarly details about why the experts think TDD is beneficial I am going to give you the bullet points why I find it beneficial;

  • Separation of Concerns
    • Separation of Concerns is one of the key principles of a good architecture.  Unit testing before, or as is often the case while, coding really helps keep a method lean.
  • Single Responsibility Principle
    • The Single Responsibility principle is strongly related to one of the other key principles of good architecture, Cohesion.  When writing a unit test for a method you get another chance to make sure that the method has a single specific purpose.
  • Instant Isolated Debug Environment
    •  Writing a unit test allows you to immediately test a specific piece of code.  You don’t have to wait for another developer to finish the piece of the UI that calls down to the piece of you are currently working on.  These alleviates the possibility of unit testing the piece of code slipping through cracks and it allows you test those scenarios you often have in the back of your mind that you are not entirely sure how or if your code will handle correctly.
  •  Regression Testing
    • Having a full suite of unit tests to run takes care of a good chunk of your regression testing.  It allows you to catch any negative effects that may occur as result of changing a piece of code.  This does not by any means resolve you, or your testers, from performing a full regression test prior to deploying code.

I highly suggest any developer who is serious about writing the best code possible to consider doing some form of TDD whether it be full on TDD where you write all your unit tests before you write any of the actual code or THMWDTM, I made that up and I am sure it won’t catch on, which stands for Test The Method While Developing The Method.  I am sure the benefits, of which I outlined what I consider the big hitters above, will far out number whatever you or your team percieve as the negatives.  I would suggest trying it, not for a complete project, but for a class or two and see what you think.  I bet you will be coming back for more.


posted on Thursday, 26 March 2009 20:57:27 (Central Standard Time, UTC-06:00)  #    Comments [6]
# Monday, 23 March 2009

The project I am currently working on I wasn’t brought in until near the end of the design process.  The negative of this is twofold.  First, I was not as comfortable with the requirements as I would have been had I been on the project since day one.  Secondly, and more importantly in the case of this entry, I wasn’t able to get down and dirty with the estimates.  I did have a chance to voice my opinion about the estimates a time or two prior to them being submitted to the PM but not having the intimate knowledge of the requirements needed to support any suggested deviance I kept quiet.  Of course in my head I was thinking the estimates where on the high side.  Let me clarify that these estimates where not just the number of hours before the system is ready for unit testing.  The data the system relies on is only available through web services…that do not exist yet…and must be written by a specific team that has a vast knowledge of the underlying data structure.  (If you can sense in my tone there will be a post on this matter…but not until I am at a different client.)  So the estimates included a design/code/unit test period that would take us up to the point where we could code no further without the web services in place.  The estimate for this “no work left” date was approximately 6 weeks.  We are now in week 3 and I can go no further without those web services in place and I have an impromptu meeting with the PM and the other developer’s tomorrow morning to see what my next steps are.

Lesson:  If being brought in on a project in a lead developer role late…insist on getting the extra time needed to get familiar with the requirements and make any needed adjustments to the estimates.

 

posted on Monday, 23 March 2009 18:55:23 (Central Standard Time, UTC-06:00)  #    Comments [2]