in

 

PhatBoyG

Coding from the Hood since '87

January 2008 - Posts

  • Assert.That(this, Is.Easy);

    I came up with this a month or two ago, but finally decided to share it. While working on Mass Transit, I was joking with Dru Sellers about how nice it was to have really good test coverage when making design changes to some all-new development code. I've had very limited opportunity for a completely new projected started purely from unit tests, so I was just impressed at how easy it was to make code changes knowing that a passing set of tests meant all was well in the world.

    You see, not all parking lots are paved with quality asphalt, generally flat, and void of any obstructions like islands and lights (see my other hobby). At work, our application is a lot of vintage C++ code, a ton of stored procedures packed to the hilt with domain logic, and nearly zero percent unit test coverage. Since adapting agile development, it is something that has been missing from our process. In our latest iteration, we've started using unit tests (with NUnit) to design our interfaces and classes. At the same time, we're integrating Mass Transit to support the loosely coupled layer of application services (which include object translation, communication with high-latency remote systems, and lazy auditing of transactions). Aside from a few basic web services to support remote client application support tools, this is the first C#/.NET development that is being done as part of the main application.

    So back to our story, my first project with really good test coverage exposed me to a lot of new things. From a TDD perspective, I'd read about it, used it to build some basic tests for various classes, and thought I had a pretty decent understanding of it. In this new project, I also learned how to use Rhino.Mocks (which took the test run time from 40-50 seconds down to 1.83 seconds on average), a very powerful tool for making an interface behave as you would expect an implementation of that interface to behave. The use of mocks has really helped me focus on actually writing tests and building a single class at a time. Prior to using mocks I would jump around creating additional classes as I defined new interfaces just to be able to continue writing my unit tests on the original class. By using a mock, I'm able to simulate the behavior of the other class without losing focus.

    As my appreciation for TDD grew, I jokingly dropped a slogan into a chat window (using Skype, of course, aren't you?):

    Assert-That-This

    I got a few chuckles, and thought it would make a great t-shirt to wear to tech events like code camps. So I threw together a quick online store so that I could order one for myself. I showed it to a few others (like Joe Ocampo, who suggested the slightly less offensive, yet subtly more suggestive variant) and decided to make it available to anyone that wanted one. So if you like it, grab one for yourself and maybe I'll see you wearing it at ALT.NET Seattle!

  • Resharper 3.1 Solution Wide Analysis

    Since early last year, I have been using Resharper to increase my .NET coding productivity. After seeing the product used at a Code Camp, I was intrigued by how it make test driven development so much easier. I started on version 3.0 and JetBrains dropped 3.1 on Christmas Eve so I checked it out over the holiday break.

    One of the features that first interested me was the Solution Wide Analysis. I turned it on, looked at the badly drawn green circle in the corner of the Visual Studio 2005 IDE, and went, OK. It took me a bit more time to recognize how this new feature was going to improve my skills yet again.

    The first thing I learned was that the blinking light was not the real power behind solution wide analysis. The power was that Resharper was working hard eating up those idle CPU cycles to verify the integrity of my entire solution. It wasn't until I double clicked and put the window as part of my IDE into practice that I saw the true power (of the force?).

    Picture 2.png

    The above image shows the errors in solution window with a clean bill of health, no problems with compilation. The next image shows what it looks like when things get broken:

    Picture 3.png

    I slipped the window right under my solution explorer, giving me a constant view of my code status. When refactoring, it makes it easy to see all the affected files at a glance. Very cool. But I do have a couple of nags on this feature:

    • I really don't need a tall bar eating space at the top of the window for a repeat of the red/green indicator -- get rid of it
    • I would like the option to expand all the nodes in the tree by default instead of only showing the file names

    The new solution wide analysis feature is a great red/green indicator to see the impact of code changes. If you haven't upgraded to 3.1 yet, what are you waiting for? And if you aren't using Resharper yet, what is holding you back?

Copyright Los Techies 2007. All rights reserved.
Powered by Community Server (Commercial Edition), by Telligent Systems