The Sherpa Project

Keep your tests easy to read…

A while back, I was looking for an answer to a Javascript question and I ended up finding the answer in this Javascript reference. More important than finding the answer to my question, I was intrigued by how clear the reference was with minimal text and the fact that the reference was put together as a list of assertions. It came down to the code being self-documenting and being very easy to understand.

Ever since I saw the Visibone references (all of which are very good), I have tried to learn new languages taking a test-driven approach to learning the legend. Usually, the first thing I learn about is a test runner that I can use for the language and then I play with the language by using the test runner and creating a bunch of tests. Everything is self-documenting and I can go back and tweak examples when I want to expand on my knowledge or find out how certain scenarios work. Best of all, I have a record of my learning and when I switch versions of the language or library, I can simply run my tests to see if anything I know has changed since the last time I used the language or library.

I recently started playing with the prototype library, and this approach has been a great asset. I can learn a little at a time and review my progress at any time. The prototype library is a Javascript library and I started out by using the script.aculo.us unit testing library (which is built on top of prototype).

My approach was to create a new .Net website, create a master page with all of the javascript references, and then adding new content placeholders for each logical area that I'm learning about.

My test page looks like this…

…and the tests look something like this…

This has been a great way to learn prototype and I think I'm probably going to do this more and more moving forward. Just about every language seems to have a unit testing framework and I like the idea of having code that I can go back and execute.

The March 21st edition of .Net Rocks was my favorite show so far. The topic was Test Driven Development with Jean Paul Boodhoo and the show was very good. Jean Paul Boodhoo provided some great insights into TDD, Mock objects, and agile approaches to software development. 

Whether you're a devoted TDD advocate or not, the show is worth checking out. I can also recommend checkingout Jean-Paul Boodhoo's blog.

James Shore has written a very straight-forward introduction to dependency injection. I agree with James, the concept is simple, powerful, and usually appears to be complicated because of the way it is explained. You can find the article here.

Thanks to the outcry from the community, Microsoft is in the process of changing the Guidelines for TDD page. I applaud Microsoft for listening to the community and quickly taking the proper steps to rectify the faulty guidance. You can read more in this post from Rob Caron.

… are wrong. The guidelines are an extreme disapointment in my opinion. This topic has been brought up lately on the xp mailing list and there is starting to be an outcry from the tdd community. TDD (by definition) means test-driven.

I hate the fact that you can generate tests from code with the new testing tools. I think there is probably value with the “generate test

Anyone that knows me knows that I’m a huge fan of TDD. Not just TDD for testing - but TDD for architecture (and many other things too).

I’m currently working on a project where I generate a lot of pdf documents. I had a couple of big-picture ideas for how to write the code, but there were a few things that I knew would emerge and become clearer as I starting writing the code. When we finally picked a pdf-library for the document generation I quickly found out that the API was horrendous. There were areas that this significantly complicated the “ideal” architecture for the application (at least the way I had originally envisioned it).

I didn’t try to do much BDUF (intentionally), so I figured I would just let the code and the circumstances tell me what to do and this pretty much how it went…

1. I wrote the implementation for the drawing (the api I’m using is based on a nasty coordinate system used for generating pdf files) of the first document.
2. I wrote the implementation for the drawing of the second document, and the third document, and the fourth document.
3. I noticed that I was duplicating a *lot* of code (it was nasty code too).
4. Since I had tests around everything, I figured I could easily refactor and remove the duplication. Unfortunately, I couldn’t figure out how to refactor the duplication out to something clean. At this point, I got a little worried. I typically like to remove duplication as soon as I notice it. I had a lot of duplicated code in three different places and to say the least — I hated knowing that it was duplicated. I wasn’t sure of what to do so I kept duplicating code. The code that was being duplicated wasn’t one-for-one, but it was close enough that it was obvious that at some point it should by consolidated and reused.
5. I wrote the implementation for the fourth document.
6. I started to see some common patterns where I could start to pull out the duplication.
7. I wrote the fifth implementation.
8. I had a good weekend.
9. I started refactoring and was finally happy (thank god for tests).

I usually follow the red-green-refactor cycle but in this case I just wasn’t sure how to refactor. After lots of duplication and more experience I learned more about the API that I was using and this allowed me to refactor back into code that *felt* right. I still have some duplication, but I’m sure as I write a few more implementations that the duplicated portions will work themselves out like the other duplications did.It’s interesting, because I would usually have recommended to remove the duplication at the first (or second) sight of the repetition.

The Tech·Ed Webcasts have been posted here.

My webcast (Test-Driven Development with BizTalk Server 2004) is located in the Connected Systems Infrastructure webcasts.

Thanks to everyone from Microsoft who let me do the webcast and for Drew for recommending the webcast in the first place. I had a great time doing the webcast and covering a topic that is a blast to talk (and think) about.

For anyone in the Ohio area, be sure to stop by at the .NET Development Best Practices/Tips-Tricks event on Friday January 21st. I’ll be giving a session on Test Driven Development and the lineup for the event looks great.

The event is free and open to the public. You can register at the Microsoft Events site.

The lineup is…

1. Implement a Service Gateway with COM Interop and Web Services – Dave Donaldson, Arcware
2. Building Web Services – Drew Robbins
3. Test-Driven Development in .NET – Ben Carey, NuSoft Solutions
4. Pimp Your IDE – James Avery, Infozerk
5. Client-Side Scripting with ASP.NET – Steve Caravajal, MAX Technical Training
6. What’s New in the Visual Studio 2005 IDE, ADO.NET 2.0, and WinForms 2.0 – Alex Lowe, Microsoft

I was working with Drew today and preparing for our .Net Users Group presentation on leveraging open source development tools with .Net. For this presentation, we have consistently met at Panera because of the free wifi access. When we arrived this evening we were unable to connect to the wifi. At first, this seemed like a pretty big problem, but it ended up being a perfect scenario for how mock objects can provide a significant advantage..

My pieces of the presentations are centered around NUnit and NMock. In the example code that we put together for the presentation, the data layer is comprised of an external (XMethods) web service. Without wifi, we were obviously unable to connect to the web service. The wonderful part about all of this was … it didn’t matter.

Since the tests in the business layer utilized the functionality of NMock, the tests all ran as expected. The only exception to this was the suite of integration tests, which confirmed that the service wasn’t available and that the integration tests were doing their job correctly.

So, even without the core service that we needed to talk to, Drew was able to setup NAnt scripts and get Cruise working with full unit test integration. We would have been able to do a portion of this work anyway, but we wouldn’t have been able to do any refactoring of the tests or code modifications with full confidence that the code was still functioning as we expected (the test would have all failed instead of passing).

There are a variety of scenarios where mock objects can be a wonderful addition to your toolset and development process. This scenario was a prime example. We didn’t control the internet connection at Panera, but it wasn’t able to stop us from moving forward and preparing the presentation or performing the integration of the code and various toolsets.

A couple of other places where mocks (implemented correctly) can save the day include:

• When your unit tests take a long time to run (the faster the feedback the better)
• When systems are out of your control (that big mainframe app that goes down all the time)
• When systems are not always available (when that big mainframe has to be rebooted every night and takes a couple of hours to get back up successfully)
• When systems return dynamic results (such as stock prices, current temperature, the current election results, etc.)
• When a system doesn’t exist yet (parallel development, etc.)

If you are interested in learning more about how to implement mock objects in .Net, take a look at this MSDN article. The article provides all you need to know to get started with NMock up and running.