Thoughts on TDD and BDD

I just finished reading Martin Fowler's Mocks Aren't Stubs. This is a great document because it gives some names to things that I hadn't been able to name before. Classicist vs. Mockist TDD is a key distinction that we have been struggling to define as we develop more concrete testing methods at work. To know that other people, who know what they are doing, have also dealt with it helps us to know that we are not just making things up.

My key conclusion from this is that I follow a Classic TDD model. I don't want to care about the behavior of my methods and therefore I am not going to do strict mocking where I verify that certain methods have been called. The interesting wrinkle here is that I really want to use a mocking framework for the ease with which I can create a stub or dummy object. This isn't well supported in all of the frameworks, but I have heard that Moq is going to be what I want to look at.

Fowler's article linked to Dan North's BDD introduction. I hadn't understood BDD before, and I can't claim that I really do at this point, but there is some interesting content in this introduction. The first few paragraphs of this description really seems to address a number of problems that I have had with TDD and unit testing in general. Here are the questions he poses:

• Where to start?


• What to test and what not to test?


• How much to test in one go?


• What to call their tests?


• And how to understand why a test fails?

I had yet to come up with satisfactory answers to these question. But North has a simple answer for all of them: write your test names like sentences. If my test class is named FooLookupTests and my test method is named FindFooByIdTest(), I can write "Foo lookup - find foo by id." When the test classes and methods create this structure, then I am working in the right direction. When they do not create this structure, then I need to review what I am testing and refactor my tests and possibly the code under test to follow this guideline.

After this simple suggestion, North goes on to point out how he developed the BDD method from this insight. On my first evaluation of this description, I do not like it. While I like North's initial insight and I think his answer to the questions above is very insightful and useful, I can't see myself adopting a full BDD process.

Update: my coworker John mentioned that the main point of North's introduction is more that the test methods need to be named in a testShould...() format. Certainly the BDD people would argue that you are doing it wrong if your test methods aren't of this form. For my purposes, I don't think this is strictly necessary, but is a useful point to keep in mind.

Subversion Rename using Powershell

I am working on an ASP.NET project that is hosted in subversion. I mainly use the command line client to work with things, but occasionally that doesn't easily get me where I need to be. I wanted to rename a page with it's codebehind, so I did the following:

get-childitem MyPage.aspx* | %{ svn rename $_ $($_.ToString() -replace 'MyPage', 'new-page') }

This isn't anything new for powershell veterans, but it is the first time I found the immensely useful 'replace' string operation.

Zebra (alternating color) Tables in ASP.NET

This is just a small note to say that I love doing this:

<tr class='<%# ((IDataItemContainer)Container).DisplayIndex % 2 == 0 ?
 "CommonListRow" : "CommonListRowAlt"  %>'>

When using any type of ASP.Net repeating control (such as asp:Repeater). It is much more maintainable than copying and pasting code between the <ItemTemplate> and <AlternatingItemTemplate>.

Community Server Training

We have been working hard here at the ATGi world headquarters to create a curriculum for Community Server training. It is now available for registration and I am looking forward to the class in April. Check it out here for more information.

Windows Server 2008 Domain Controller Backup

All the information you need can be pulled from TechNet, but I have condensed it here.

You need to run the following command to get the system state backup, which is what you can use to restore a DC it fails and you need to restore to a different machine, or to a new install on the same machine.

wbadmin start systemstatebackup -backupTarget::

Be sure to run it in cmd and not in powershell because powershell does not like the -backupTarget: part of the command. If you normally work in PSH, then a cmd /c "wbadmin ..." will allow you to run this command.

A few other notes that are valuable:

When you are saving system state you must backup to a drive, it can't be a network share.

And can't be one of the source drives of the backup, but you can get around that. To get around the drive limitation create a DWORD in the registry at:

HKLM\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\AllowSSBToAnyVolume

and set the value to 1. This allows you to backup to a source drive of the backup. The TechNet article says there can be issues with this, but allows you to do it anyway and from what I can tell does not have issues. This is a bit frightening, but seems to be the best we can do with the tools provided.

If you have the space, you can also backup the entire machine with a job defined through the GUI (or wbadmin). This will allow you to restore to the machine the backup was pulled from. It is good idea to have both this kind of backup and the system state backup.

Microsoft would ultimately like to sell you their System Center Data Protection Manager (DPM) product and that is why there are not as many options for wbadmin as there were for ntbackup. We don't need (or have the hardware to support) DPM here, so we are currently making do with some wbadmin and some scripts cobbled together.