March 2009 Entries

So, I just ventured into tagging my blogs, partially because I think tag clouds are cool, but also it really can be helpful to find related posts.  The problem however, is I don’t know what provider I should use.  Being on GeeksWithBlogs, and thus Subtext, I can use the built in support for microformat.  However, the tag cloud works great, but the tags that I add to my post are incomplete.  Unfortunately, Subtext expects a “default.aspx” at the end of the url.  I’ve tried a number of ways to work around the issue with no luck.

What I would like to do is go back to all of my past blog entries and add tags.  I don’t want to do this until after I’ve resolve the tag link problems.  So, I guess at this point, I am interested in feedback regarding other tag providers like Technorati or  There are so many to chose from and I am not even sure using a separate tag provider is the way to go.  Your comments are appreciated.


So I just installed Live Writer and am writing this blog with it.  Integrating with my blog was painless.  I added a Code Snippet plug-in, hoping that it will work well for me.  I’ve been using CopySourceAsHtml (CSAH) to great success, but thought it best to try out the plug-ins that are available.  There are other code plug-ins, but this was the highest rated.  Do you, Dear Reader, have a favorite?

Here is a comparison between the CSAH and the plug-in:


    1 [Specification]
    2 public void the_job_end_date_should_be_set()
    3 {
    4     _view.AssertWasCalled( v => v.EndDate = EndDate );
    5 }


   1: [Specification]
   2: public void the_job_end_date_should_be_set()
   3: {
   4:     _view.AssertWasCalled( v => v.EndDate = EndDate );
   5: }

I had to set up additional styles in my blog CSS because the class names for the plug-in are different than CSAH.  It wasn’t a big deal though since I was able to simply reuse the existing styles.  Also, I lose some of the coloring that CSAH gives because CSAH grabs the colors directly from Visual Studio.  It’s not a big loss.  In fact, I have either option with Live Writer as you can see.  I just have to “Paste Special…” when using CSAH.  Maybe I will try a couple of the other code snippet plug-ins later tonight.

Live Writer advantages over built-in GeeksWithBlogs editor.

  • I have had to work around a problem with the built-in edit regarding hyperlinks.  Live Writer doesn’t exhibit the same problem.
  • With Live Writer, while writing my blog it is already displayed using my blog CSS.  With the built-in, I have to wait until after I publish.  Yikes!
  • Saving a draft is a breeze with LW.  I’ve frequently lost blog posts because of errors posting with the built-in.
  • Preview mode is nice, as it shows me what the post will look like after it is published, including blog headers, side-bars, etc.
  • Both support a Source view.
  • Plug-in support.  It took me no time at all to find a plug-in for code snippets.  There are a bunch more out there too.
  • Categories are much easier to assign.  With the built-in, the list of category checkboxes are not alphabetized and the text is frequently misaligned.

Other things of note:

  • With LW, you can specify a publish date.  Sounds cool, but I haven’t had a need for it yet.
  • I have to set up different “keywords” (Auto Linking in LW).  Fortunately, I don’t have a ton of key words yet, so, it’s not a big deal.

Visual Studio had a problem where it would added "a lot of nbsp" when toggling from Design to HTML mode with certain custom controls.  I blogged about it originally here.  It appeared to be fixed as I described on another post, but it only seemed to occur less often.

Finally, there is an official fix.  It's not truly a "hotfix" though.  It asked me to reboot to complete the update.

With my new job, I’ve not been able to take advantage of a lot of Agile/XP practices.  In a company of four, where each is effectively working on a different project, collaboration is minimal.  Also, for the projects that I am working on, the customer is very adamant about getting a detailed proposal up front, including a list of all of the screens and how they will operate.  I’ve managed to get by without too much detail, but it is still more than I am generally comfortable with.

TDD and Continuous Integration are about the only Agile practices that I have kept up.  I have neglected to document user stories and acceptance tests.  I’ve let my unit tests be the extent of my documentation beyond the initial proposal.  As much as I would have liked to use something like Fit/Fitnesse to interact with my users for acceptance, it just wasn’t going to work.

Blah, blah, blah… and more to the point.

After reading extensively about BDD, I’ve discovered that the primary purpose is not to change how tests are arranged, but to bring acceptance criteria from the customer to the code with as little translation as possible.

I’ve written hundreds of tests for my new project in the last year.  I have also extensively refactored my test code and introduced a variety of classes to simplify testing my MVP classes.  I’ve hidden as much of the noise as I can.

My tests typically look something like this:
    1 [Test]
    2 public void MyVeryWellDescriptedTest()
    3 {
    4     Test.WithExpectations( () => ...)
    5         .WithActions( () => ...)
    6         .WithAssertions( () => ...)
    7         .Execute();
    8 }

The combination of this TestBuilder wrapper along with my base test classes has really simplified my tests.  Switching to BDD style would be a lot of work and it didn’t appear that it would add a lot of benefits.  I didn’t like the fact that I would have to add a separate class for each scenario.  I didn’t like that the pieces important to my test would be broken up between multiple methods.  I didn’t like the fact that I would need significantly more lines of code noise to write my tests.

I played around with my naming conventions for my tests to be more BDD like.  I added underscores and have been a lot more verbose.  I still haven’t decided if I really like the new naming convention.

But this all misses the point of BDD.  I look at my tests and think, these are readable.  Well, I’m just fooling myself.  First, a glance at my tests doesn’t immediately give an indication of the behavior that they are testing.  Second, only someone familiar with Rhino Mocks would really understand the tests without some guidance.  Finally, you can’t call your own code readable, just like you can’t give yourself a nickname.

In fact, I have gone back to some tests that I wrote toward the beginning this project.  The tests are about nine months old.  They are not easy to read and I am the author.  They are not horrible, but I think BDD could have improved them dramatically.

I am starting a couple of new projects soon, so I think I will go full bore into BDD.  In fact, I prototyped some ideas with a coworker while he was visiting from out of town.  We both agreed that the BDD tests were easier to read, and they clearly expressed the intended behavior of the system.

What are your experiences with transitioning from TDD to BDD?

Tags: , , ,

My trial ran out a few days ago.  And I haven't posted about R# for almost a month.  I have to a few more things to share, and perhaps I can save everyone some time.

The R# team has done quite a few small things to raise the tool a step above my expectations.  There are a lot of things that may seem small, but really turn out to be significant improvements to the way I manage my code.  Simple things, like, locating new code (via refactoring) with similar declarations (fields with fields, properties with properties) have impressed me.  R# saved some me steps that I didn't even think about.

I have grown fond of the simple code cleanup suggestions when viewing a code file.  Also, I am really taking advantage of R#'s ability to add a namespace import for classes I reference in my code.  I've mentioned these things before.

The new toy I have been playing with is the Live Templates.  I was doing some pair programming last week with a coworker who was visiting from out of town.  I was showing him the TDD approach and the BDD that I am experimenting with.  I was a little embarrassed that I was typing the same pattern of code over and over again, so I created live templates for new test classes and test cases.  (I haven't quite transitioned to the BDD lingo yet.)   The Live Templates worked great!  The are amazingly easy to create and maintain, and equally fluid to use.

Just a quick look at the menu tells me that there is a lot more R# has to offer.  It's going to take a while to play with everything and adjust my coding practices accordingly.

I suppose that you've figured out that I have decided to keep R# around long term.  In my opinion is is worth the price.  I'm glad my boss thinks so too :-).

In the interest of completeness, I should mention a few of the negatives I've encountered with R#.  First, there is a noticeable performance degradation.  This is especially significant when viewing my ASPX files.  The screen can freeze for a couple of seconds on occasion.  Not fun.

Second, I had to get a separate download release (untested) to correct a type recognition problem in ASP.Net.  Even that update only cured part of the problem.  It is painful when the project compiles, yet R# reports an unknown type and refuses to provide intellisense.  I had to turn off R# intellisense in order to get around the problem.

Finally, related to the performance issues, but really more of an annoyance.  The initial load time for Visual Studio is greatly affected by the time it takes to load all of the R# libraries.  Loading VS has nearly become cup of tea time (I don't drink coffee) recently.

Despite these drawbacks, I feel R# will significantly improve my productivity.  For those of you considering R#, get off the fence and buy it (or implore your boss to do so like I did).  It's worth it.