Book Blog

Corey Haines recreated my TDD Kata on his KataCasts blog.  (click here to learn more about TDD katas)

Since Corey is an experienced TDD practitioner I was honored that he’d given it a go, and was eager to see the video. Later, corey asks for my remarks on it, which i will gladly put here. In general, Corey’s video is a great piece of TDD work to watch as an example of a master TDDer doing his thing. Everything flows gracefully and the code produced is simple, readable and of course – works.

I especially loved the large amount of merciless refactoring Corey made during the Kata. As you TDD you should not cut any corners in the refactoring area – and almost after every passing test or two, Corey does refactoring to some very simple code patterns.

Another worthy note – Corey takes care in refactoring the tests as well throughout the kata. Kudos!

A few things that stood out for me can be thought of as very little things – and are mostly questions:

1. Partial Test: at some point, Corey seems to be writing the tests incrementally as well, in that he writes an empty test that passes, and then fills in the test itself to see it fail (which is usually where I start). I wasn’t sure why he’d do that, but the reasoning could be that he wants to make sure the environment works for the test. since he does it all in Ruby, which is a more forgiving environment for typing errors, this might be it.

2. Always passing test: very early on, in the second test actually, Corey creates a test that asserts that sending “0” returns “0” – which passes and never fails. That is because by default empty strings as input return zero. I do it a bit differently – i try to start with a failing test that drives more functionality, and if i can find a way to make a test for “0” fail as well to being, i will do it (so that i can ‘test the test’ in TDD style).

   A different way: Don’t write a passing test for “0” input. instead write a failing test for “1” input. Another options would have been to indeed start with a passing test for “0” input, but then to go production code and deliberately return –1 to see the test fail, then fix it to return “0”, see the test pass again, and move on to the next test.

3. Magic inputs: Corey sends in various seemingly random, out of the air numbers as inputs to the tests starting from the third test onwards. For example, to a reader who sees a test that says “sending in 5 returns 5” that reader might ask themselves “why 5? why is 5 so special? should I also use 5 in my tests?”.

   A different way: To avoid such confusion i like to stick to the lowest common version of an input that still proves the application wrong. if sending in “1” produces the same result as sending in “5” then my all means i will send in “1”. If the input is 2 digits, I’d send in “10”, “100” and so on. If the input still does not make sense I would put it in as a variable named “SINGLE DIGIT NUMBER” to explain to the reader what is so special or not so special about this value.

4. The simplest Test:Corey wrote the tests for inputs with \newline characters without considering the most basic test for this kind: a simple string containing only a new line character (equivalent to an empty string). I agree that not everyone would pick up on this as an idea, since you might feel this is an invalid input into the system. nevertheless, when I teach TDD this is the way i teach the kata. It feels like a more natural incremental evolution of the code and tests, and a good way to send the message that anything can be divided into small increments if you want to.

5. Refactor to un-readability: At some point Corey refactors the code that handles delimiter characters into a single line of Ruby code. while it isa form of refactoring, i found that the code after refactoring was much less readable than it was before.

   A different way: I try to avoid any “immediate if”s or single line “smart” statements that feel more “smart” than “simple”. When i have to choose between length and readability, i will choose length every time. this makes sure the reader is always comfortable with the code.

Summary:

These small things aside, I think Corey’s video is a great example of TDD in practice! Go watch it.

Scott Hanselman took me in for a 30 minute interview about Unit Testing Dos and Don’ts in his podcast, Hanselminutes. It was a pleasure, and I hope to be there once more about other topics. Maybe in TechEd Berlin..

Have a listen

here are the questions that teams and team leads should be asking themselves on a daily\weekly basis.

There are more, but these are the basics, to me. It’s part of the summary for the talk “Beautiful teams I am giving at SEConf and NDC. we do a lot of this stuff over at work, and it’s proving itself on a daily basis.

Whole team

1. What can we automate?
2. where are we "Reinventing the wheel"?
3. what are the tools that slow us down?
4. what tools can we use better?
5. are there bugs that I could have found earlier? how do I make sure I find them earlier?
6. when do we find out we built the right thing?
7. when do we find out our code\design sucks? how can we make that earlier?
8. How do we show progress at the team level? at the management level?
9. How many meetings does each dev have every week? how can we remove them?
10. Are we building by feature or by layer?
11. can we make all our team sit in the same place?

Team Lead

1. daily: what bottlenecks exist in the team? what have I solved?
2. will my devs be better in a month or two than they were before? if not, how do I make that happen?
3. what prevents my devs from working? what am I doing about this?

What are your thoughts on this style of writing?

• Specifically the “Explicit” way of defining arrange, act and assert scopes.
• also, given the name of the test, where should the call to “OnApplyTemplate” be (if you’ve never seen the code)?
• which version makes more sense to you? A, or B?

version A:

version B:

The time has actually come. After 2.5 years, and two kids, my book is finally done and is available in full form as an EBook. at the end of the month it will be in print form. Now would be the time to get it, when it is still at a “pre-order” pricing. Get the preorder price either at Manning(along with the EBook) or at the amazon page.

I love the cover image. How about we call this “The Samurai book” from now on?

This is the book that I wished I had when I started out writing my first tests, and that combines my knowledge about unit testing from the past 5-6 years or so working with companies on real projects (and real failures).

It contains things I have not seen in other places – writing readable, maintainable and trustworthy tests, as well as guidelines on how to review someone else’s tests and what to watch out for.

I was lucky to have the foreword written by no other than Michael-Legacy-Code-Feathers himself, and with some great quotes including one from Kent Beck about the book.

Here is the Table of Contents.

Free Chapters

The book comes with two free chapters:

Chapter 1 – The basics of unit testing(PDF)

Chapter 3 – Using Stubs to Break Dependencies (PDF)

Or get the full book

Book description:

Unit testing, done right, can mean the difference between a failed project and a successful one, between a maintainable code base and a code base that no one dares touch, and between getting home at 2 AM or getting home in time for dinner, even before a release deadline.

The Art of Unit Testing builds on top of what's already been written about this important topic. It guides you step by step from simple tests to tests that are maintainable, readable, and trustworthy. It covers advanced subjects like mocks, stubs, and frameworks such as Typemock Isolator and Rhino Mocks. And you'll learn about advanced test patterns and organization, working with legacy code and even untestable code. The book discusses tools you need when testing databases and other technologies. It's written for .NET developers but others will also benefit from this book.

What’s inside:

• Test Review Guidelines
• How to create readable, maintainable, trustworthy tests
• Stubs, mock objects, and automated frameworks
• Working with .NET tools, including NUnit, Rhino Mocks and Typemock Isolator

See other reviews:

• Review #1: NerdDinner

Here’s the second video review of Unit Tests. This is another one written by Microsoft – ASP.NET MVC (source).

First, it’s important to state how surprised I was by the high quality of the tests in MVC. The tests are readable, maintainable and trustworthy, with very little issues that I could find. whatever Issues I found are rather easy to fix. In any case, if one is looking for examples of systems written in what seems almost entirely in TDD, or at the minimum with very good testing guidance, ASP.NET MVC should be a good stop to look at.

Issues discussed in this video:

• Implementing RowTest with MSTest, and the importance of naming (14:00)
• Verify() that is splitted from the mock expectations (17:00)
• some naming conventions
• Over-specification in tests (mainly more than one mock object per test)
• verifying mocks when it’s not required
• logic inside tests (concatenation)
• test factory methods with too much logic
• a very good example of when multiple asserts is really bad (11:50)

Again – I’m very pleased with the test quality. Now is the time to make sure the things above are fixed. they are still important!

We’ve come to a nice way of deciding upon features in the Isolator API. This is what happens when your end product is an API for programmers.

First, we realized that we must argue about it. For each type of new feature in the isolator API, we put up on the white board several version of the API that we can’t seem to decide about, and then ask everyone on the team to say what they think. If everyone agrees, then we ask people to defend the opposite side and explain why an API is not good.

We came to several agreed upon values for the C# API, that help us judge the usability of it:

• Consistency – is the new API consistent with the other APIs that already exist, or does it go against the regular way things are done?
• Discoverability – If a user knew they wanted to do thing X, would they know to use the API without help? simply from intellisense?
• Explicitness – we decided early on to be as explicit as possible about the API, so that the least guessing needs to take place by the user
• Single point of entry – everything should start from a single point (Isolate.Something())
• Readability for the reader, not the writer (if you didn’t write the test would you find it easy to understand what it does?)
• Single way to achieve things – is there more than one way to do a task with the new API?
• Backwards compatibility – do we break an existing feature and cause some heartache  for users?

We measure the various versions of an API by putting it in a matrix and setting “V” or “X” on each of them (if we can’t agree it’s a V with a line on it).

then we have a better idea of what makes more sense.

I admit we still haven’t come up with a single set of values for the VB API, but I’ll try to define it here:

• Does not require use of Action<T>
• Consistent with the way a VBer would use other APIs
• Explicit
• Readable
• Single way to achieve things
• Backwards compatible

note that “single point of entry” is not included. That was a design decision we made early on.

I’ve been asked quite a lot recently whether one can write unit tests and isolate logical code that runs inside a silverlight application. Up until today my initial answer was  ‘no’ because silverlight runs under different versions of mscorlib.dll.

however.

Today I actually gave it a try and realized that writing unit tests (not integration tests, as the silverlight test framework allows) against silverlight based code is possible and quite easy. Just like any other code that relies on a third party platform (like sharepoint code) the silverlight related code might have various dependencies.

I’m going to show how to use Typemock Isolator to overcome a couple of simple silverlight dependencies (using HtmlPage) and how to setup a test project against a silverlight project (with NUnit or MsTest)

Assumptions:

1. You have an open solution
2. the solution contains a silverlight class library or silverlight application project

To setup a test project against silverlight using MSTest:

1. Add a new test project to the solution
2. Remove all the existing classes (Database test, ordered test etc..) so that you are only left with the unit test class (UnitTest1).
3. Remove all useless comments and crud code from the test class so that you are only left with a test method (no comments, not even the TestContext)
4. Add a reference to the silverlight versions of “System.dll”, “System.Windows.dll” to the test project. (usually located under “C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies\” (remove existing reference to system.dll if you need to first)
5. Add a reference to the project under test
6. You can now write tests against the object model (standard classes)

To setup a test project against silverlight using NUnit or MbUnit:

1. Add a new class library to the solution as your test project
2. Add a reference to the silverlight versions of “System.dll”, “System.Windows.dll” to the test project. (usually located under “C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Reference Assemblies\” (remove existing reference to system.dll if you need to first)
3. Add a reference to the project under test
4. You can now write tests against the object model (standard classes)

How to break the dependencies

Now, here is a simple example of code that has a silverlight dependency we’d like to test:

Let’s say we have a class in the silverlight project called ChatSession (I’m basing this on ScottGu’s Chat demo). but it’s constructor looks like this:

What if we wanted to control during our test whether the page is enabled or disabled?

Here’s one way to do it using Isolator:

1. In your test project add two references under the .NET tab: “Typemock Isolator” and “Typemock ArrangeActAssert”
2. Write the following test:

Using Isolate.WhenCalled() we are able to circumvent any method (static or not) to return whatever we want, or throw an exception.

Here’s a more interesting case. Let’s say we have a method that modifies the current page and shows some html to the user in a span tag:

here is one way to write a test that makes sure that the right text is set into the message element in the page, without needing to have a real page present:

There are several things to note here:

1. HtmlElement is Sealed has an internal constructor, but we can still create a fake instance of it using Isolator. None of the other frameworks can do this.
2. We are returning a fake object from a method call chain (HtmlPage.Document.GetElementById ) without needing to create a separate stub for document. None of the other frameworks can do this (especially since it is based on a static method call to begin with)
3. We assert in the end that the method was indeed called with the correct arguments without needing to change a single piece of code. Granted, I wouldn’t write code like this (I like decoupling!) but sometimes you just don’t have the ability to change existing code.

If you are developing an open source silverlight project, it is important to note that there is a free full version of isolator for open source projects with full functionality.

These are just the beginning of my journey into silverlight unit testing. I’m looking for good code examples that you might want to test, with various dependencies that need breaking. your comments are appreciated.