Just wanted to quickly note that I tracked down the performance issue in Rhino.Mocks and patched it. I also updated the original post with the new numbers. Enjoy!

I've complained before that Mocking is Slow but I never really dove further into it. Today I decided to actually compare Rhino.Mocks to other mock frameworks on a pure performance basis to see if it was a global problem. I timed 2000 unit tests across 100 classes with 20 tests each. The results were a bit surprising:

That's right, according to these tests, Rhino.Mocks is at least 3 times slower than the other frameworks when under heavy load in TD.NET and five times slower in the console according to these tests. It's also interesting to note that TypeMock is faster than Moq in TD.NET, but slower in the console runner.

While running the Rhino.Mocks tests it is very clear that there is a degrading performance issue. All the other frameworks executed tests with a near constant speed per test, but Rhino.Mocks slowed down noticeably about half way through.

Please feel free to try it yourself, grab the project here. You should be able to just run the 4 strategy .bat files (run-rhino, run-moq, run-tmock-reflective, run-tmock-natural). Let me know if you find anything interesting.

As some of you who follow me on twitter know, I've been working on Yet Another Context/Specification Framework as an experiment. Yeah, I know we already have NSpec and NBehave, and they're great and all, but MSpec takes things on from a slightly different angle, and it's just an experiment (for now). Here's a sample Description:

[Description]
public class Transferring_between_from_account_and_to_account
{
  static Account fromAccount;
  static Account toAccount;

  Context before_each =()=>
  {
    fromAccount = new Account {Balance = 1m};
    toAccount = new Account {Balance = 1m};
  };
  
  When the_transfer_is_made =()=>
  {
    fromAccount.Transfer(1m, toAccount);
  };
   
  It should_debit_the_from_account_by_the_amount_transferred =()=>
  {
    fromAccount.Balance.ShouldEqual(0m);
  };

  It should_credit_the_to_account_by_the_amount_transferred =()=>
  {
    toAccount.Balance.ShouldEqual(2m);
  };
}

And a TestDriven.NET run:

------ Test started: Assembly: Machine.Specifications.Example.dll ------

Transferring between from account and to account
  When the transfer is made
    * It should debit the from account by the amount transferred
    * It should credit the to account by the amount transferred


2 passed, 0 failed, 0 skipped, took 0.79 seconds.

Err, What?

Different eh? The idea was heavily inspired by Scott Bellware's SpecUnit.Net framework he showed at the ALT.NET conference. It also took heavy cues from RSpec and my insanity. I realize that the the code doesn't look much like C# code and I'm OK with that. Many have and will ask why I don't just use Boo or RSpec w/ IronRuby eventually or even one of the existing Context/Spec/BDD frameworks. Those are good questions, but my main motivations are tooling and syntax. I enjoy the tooling I get in C# and I personally like the syntax in this library considering the limitations imposed by C#.

How's it work?

The simplest way to describe it is to compare it to a normal *Unit style testing framework:

• Description = TestContext
• Context before_each = SetUp
• Context before_all = SetUpFixture
• Context after_each = TearDown
• Context after_all = TearDownFixture
• When = Also SetUp, but happens after Context before_each
• It = Test

Rather than methods and attributes, MSpec uses named delegates and anonymous functions. The only reason for this is readability. You'll also notice that the fields used in the context are static. This is necessary so that the anonymous functions in the field initializers can access them. Probably the first thing you noticed is the =()=> construct. I won't mention the names that this was given on twitter, but I think it's an acceptable thing to have to deal with in exchange for the cleanliness of the rest of the syntax.

Ok, you're crazy, but how do I try it?

First, this is a very rough cut. Everything is subject to change as we experiment with the language. That said, here's how you play with it:

1. Grab the drop here.
2. Extract it somewhere. Put it somewhere semi-permanent because the TestDriven.NET runner will need a static location for the MSpec TDNet Runner.
3. If you want TestDriven.NET support, run InstallTDNetRunner.bat
4. Check out the example in Machine.Specifications.Example. Note that you can run with TD.NET.
5. Create a project of your own. Just add Machine.Specifications.dll and get started.
6. Send me feedback! Leave comments, email me, tweet me, whatever.

Also, this is part of Machine, so feel free to take a look at the code and/or submit patches. There's also a Gallio adapter in there, but I didn't include it in the release as it's not quite polished enough yet. If you're interested in it, talk to me. Special thanks to Scott Bellware, Jeff Brown and Jamie Cansdale for their help and support.

Currently in Rhino.Mocks, making mocks fire events and ensuring that an event on your SUT was fired are both awkward and verbose at best. Here is an example of both things at once:

[Test]
public void ViewFiresBeginDrag_Always_FiresChangedEvent()
{
  IEventRaiser raiser;
  bool eventFired = false;
  using (Record)
  {
    The<ICardView>().BeginDrag += null;
    raiser = LastCall.IgnoreArguments().GetEventRaiser();

    Target.Changed += (x,y) => eventFired = true;
  }

  using (Playback)
  {
    raiser.Raise(The<ICardView>(), EventArgs.Empty);
    Assert.IsTrue(eventFired);
  }
}

Nice eh? First, is there a better way to do either of these things that I'm missing? Please tell me if so. Next, if not, what can we do to clean this up?

Well, Ayende and I discussed this in the past and Ayende spiked it and asked for feedback. The feedback was mixed and for one reason or another it never made it into Rhino.Mocks that I know of.

Well, today while I was working on Machine.Testing and another side project, I decided to give something else a shot. What I ended up with is this:

[Test]
public void ViewFiresBeginDrag_Always_FiresChangedEvent()
{
  using (Record)
  {
    PrimeEventFiringOn<ICardView>(x => x.BeginDrag += null);
    Target.Changed += NewEventFireExpectation<EventHandler>();
  }

  using (Playback)
  {
    FireEventOn<ICardView>(EventArgs.Empty);
  }
}

Better, but I still don't think it's perfect. Also, it probably requires some explanation, so let's pick it apart piece by piece:

    PrimeEventFiringOn<ICardView>(x => x.BeginDrag += null);

=> +=??? Ugly huh? I really wish we could just refer to an event somehow without having to do +=/-=. At least I'm not using vb though... Alas, we cannot access them easily so we're stuck hacking away like this. So this particular method will basically get the mock or stub ICardView.BeginDrag ready to be fired. This needs to be done during the record phase it seems. You can only prime one event at a time per mock, so if you need to do more than one you can revert to the normal Rhino.Mocks syntax.

    Target.Changed += NewEventFireExpectation<EventHandler>();

This was a fun method. This method actually creates a new DynamicMethod in the signature required by the event and creates a new delegate. The method tracks whether or not it was fired, and at the end of the Playback phase in my fixture it will assert that all of the events were actually fired.

    FireEventOn<ICardView>(EventArgs.Empty);

This actually fires the event we set up in the Prime call. It can only be called after you've primed an event.

So, the whole thing is kind of "magic", but it's less code if you can accept the magic. I think we can make things even better though, but it'd require changes to Rhino.Mocks and it's time for bed so maybe Ayende can swing by the Eleutian office while in Seattle and we can work on it. Here's what I'm thinking:

[Test]
public void ViewFiresBeginDrag_Always_FiresChangedEvent()
{
  using (Record)
  {
    Target.Changed += Mocks.CreateEventHandler<EventHandler>();
  }

  using (Playback)
  {
    EventRaiser.Raise(() => The
().BeginDrag += null, The<ICardView>(), EventArgs.Empty); } }

There's probably more you can do with the CreateEventHandler syntax like add more specific expectations, assert its not fired, assert that it's fired X times, etc. The EventRaiser syntax is ugly, but it doesn't involve strings or the fire from the right hand side like the syntax I mentioned at the beginning of the post.

You can get the source here, but I warn you it's first draft and there are hacky bits.

Oh, and here's some example tests using the TestsFor fixture:

[TestFixture]
public class CardPresenterTests : TestsFor<CardPresenter>
{
  private Card _card;

  public override void SetupContainer()
  {
    Override<ICardView>(With.Stub);
  }

  public override void BeforeEachTest()
  {
    _card = new Card(0);
  }

  [Test]
  public void OnBeginDrag_Always_SetsIsInFluxToTrue()
  {
    using (Record)
    {
      PrimeEventFiringOn<ICardView>(x => x.BeginDrag += null);
    }

    using (Playback)
    {
      FireEventOn
(EventArgs.Empty); Assert.That(The<ICardView>().IsInFlux, Is.True); } } [Test]
public void OnBeginDrag_Always_FiresChangedEvent() { using (Record) { PrimeEventFiringOn<ICardView>(x
=> x.BeginDrag += null); Target.Changed += NewEventFireExpectation<EventHandler>();
} using (Playback) { FireEventOn<ICardView>(EventArgs.Empty); } } }

Daniel Cazzulino, author of Moq posted a good comment on my last post where I suggested looking into a Mockito like syntax for .NET Mock Frameworks.

On the surface, Mockito's approach seems good. But if you do the "true" comparison, you'll see that stub(...) is exactly the same as mock.Expect(...) in Moq.

Then, when you do verify(...), you have to basically repeat the exact same expression you put in stub(...). This might work if you only have a couple calls to verify, but for anything else, it will be a lot of repeated code, I'm afraid.

I thought this too. See my comment here from a month ago. Szczepan made a good point and I've thought about it more since then.

When combined with my position on loose vs strict mocks (almost always use loose), I'd say that *most* of the time you are either stubbing or verifying. Meaning, if you're verifying you don't need to stub unless of course that method returns something that is critical to the flow of your test, in which case you don't really need to verify, because the flow would have verified. That's a mouthful, but does that make sense?

I haven't used mockito, and I know there are times I use Expect.Call with return values that matter (which would essentially require you to duplicate stub & verify), but maybe that's a smell? Maybe if you think you need that you can do state based testing or change your API?

Here's an example Test using Rhino.Mocks:

[Test]
public void SomeMethod_Always_CallsSendMail()
{
  IMailSender sender = mocks.DynamicMock
(); UnderTest underTest = new UnderTest(sender); using (mocks.Record()) { Expect.Call(sender.SendMail()).Returns(true);
} underTest.SomeMethod(); mocks.Verify(sender); }

And some code this is testing (obviously not test driven, but you get the idea):

public void SomeMethod()
{
  if (!_sender.SendMail())
  {
    throw new Exception("OH NOS");
  }
}

Notice that here we would need to stub and verify separately with Mockito like syntax. This would look something like this:

[Test]
public void SomeMethod_Always_CallsSendMail()
{
  IMailSender sender = mocks.DynamicMock
(); UnderTest underTest = new UnderTest(sender); Stub.That(() => sender.SendMail()).Returns(true);
underTest.SomeMethod(); Verify.That(() => sender.SendMail()).WasCalled(); }

This may violate DRY, but what if you designed your API differently? Maybe SendMail should throw an exception on failure instead of returning a boolean? This would make the return value unnecessary and remove the need for the Stub call. Clearly you can't always do this, especially with unwrapped legacy or API code, but it's something to think about.

Also, I think you shouldn't be verifying more than one method generally to go along with the one assert/test rule, so a single repeat would not be that horrendous. Heck, you could even do:

[Test]
public void SomeMethod_Always_CallsSendMail()
{
  IMailSender sender = mocks.DynamicMock
(); UnderTest underTest = new UnderTest(sender); Stub.That(var sendMail = () =>
sender.SendMail()).Returns(true); underTest.SomeMethod(); Verify.That(sendMail).WasCalled();
}

I think the syntax would lead to better, more concise tests. But maybe it would just be too annoying? I wouldn't know until I tried it for a while I guess.

(Note: I'm going to speak about .NET mock projects here for the most part, but most of them have Java quasi-equivalents.)

The original mocking frameworks like NMock required you to setup expectations by passing strings for method names. This was fragile and made refactoring more difficult.

A few mock frameworks now allow you to define expectations and mock results in a strongly typed manner. Rhino Mocks and TypeMock use a record/replay method to setup expectations. The record replay method is mostly necessary because the same calls are made on the same objects under two different scenarios. This leads to a few issues.

The first issue is confusion and barrier to entry. Many people have complained that the Record/Replay method is not straight forward and the whole paradigm is confusing. There are also complains about the naming, are you really recording and then replaying? It's just kind of a strange thing. Of course most of us learn to live with it, understand it, and accept it for what it is. Recently though, a few mock frameworks have popped up that do away with this model.

In the .NET world we have Moq. Moq gets rid of the need for record/replay because recordings have a very different syntax. They use lambdas instead of actual calls to the mock object. This allows the framework to know when you are recording an expectation and when you are fulfilling an expectation. It adds a bit of noise in the form of "() =>" but all in all it's not bad. Of course this requires C# 3.0, but it's good to keep looking ahead.

In the Java world we have Mockito. Mockito also does away with the record/replay model but it does it in a different way. At first I wasn't a fan, but thinking about it more, I like it. Mockito has two main apis, stub and verify. Stub is equivalent to SetupResult.For, and verify is equivalent to Expect.Call with a verify. The interesting bit is that the stubbing happens before the the class under test is invoked and the verifying (which includes describing the method to be verified) happens after the class under test is invoked. This is best shown with an example stolen from the Mockito site:

  
  //stubbing using built-in anyInt() argument matcher
  stub(mockedList.get(anyInt())).toReturn("element");
  
  //stubbing using hamcrest (let's say isValid() returns your own hamcrest matcher):
  stub(mockedList.contains(argThat(isValid()))).toReturn("element");
  
  //following prints "element"
  System.out.println(mockedList.get(999));
  
  //you can also verify using argument matcher
  verify(mockedList).get(anyInt());

Obviously it would take a bit of imagination to arrive at a .NET equivalent, but you get the idea. I like this because the normal test structure is Setup Stuff->Do Stuff to Test->Verify Stuff did what it should have. The normal record/replay model requires you to set up verifications before you actually Do Stuff (though you call VerifyAll afterwards). This is a bit less natural. I feel syntax like this (yeah, I like the new NUnit syntax) would be more intention revealing:

Assert.That(() => someMock.Foo(), Was.Called);

Or:

Verify.That(() => someMock.Foo()).WasCalled();

Then you would stub like this:

Stub.That(() => someMock.Bar()).Returns(3);

Note: No idea if this is feasible or makes sense or not, my lambda experience is limited to light reading, but you get the idea. I'm sure the syntax could also be prettier.

Rhino.Mocks is my current mock framework of choice. I'm used to it, I've lightly contributed to it, and I've been working with it for a while now. Despite that, I do think that there is definitely more to explore in the mocking arena especially with C# 3.0.

There are lots of other fun things to talk about too... like TypeMock's magic, but that's another day still...

Sean Chambers asked how we work with a published branch so I figured I'd post on the topic since it's a somewhat interesting one. It's not trivial and it took us a few tries to get it where it is now, and it's still not quite right.

The first step to using a published branch is to create the branch. You can do that like this:

svn cp https://yoursvnserver/svn/project/trunk \
https://yoursvnserver/svn/project/branches/published \
-m "Branching published"

After that, we actually check out the whole branch. It's very useful to have both the pubilshed branch and the trunk on one machine. Note that this isn't necessarily trivial, and its feasibility entirely depends on your build. Having a location agnostic build is a very important thing, and this is one of the reasons.

Now we have both trunk and published branches. We almost always do all of our work in trunk and then merge over to published. Jacob actually wrote a PowerShell script to make the merges easier (from merge.ps1):

param([int]$rev, [string]$reverse)

if (!$rev)
{
  echo "Merge.ps1 REV [REVERSE]"
  return;
}
if (!$reverse)
{
  $branch = "Published"
  $url = "https://yoursvnserver/svn/project/trunk"
}
else
{
  $branch = "Trunk"
  $url = "https://yoursvnserver/svn/project/published"
}

$previous = $rev - 1
$range = $previous.ToString() + ":" + $rev

pushd $branch
svn merge -r $range $url
popd

The reason for doing most of the work in trunk is that often times any issues we run into on the published site will still be issues in the trunk. It makes sense to apply the work there first and then merge it over. The only time we patch published is when we need to apply a hack to make something work so that we can fix it the right way on the trunk later, or maybe that feature is completely different on the trunk and the fix would not apply. Of course this is dangerous and you have to be sure to remember to fix the underlying issue in the trunk before publishing from trunk again. Bug trackers help with that.

That brings us to publishing from trunk again. Merging everything from trunk into the published branch is a giant pain, and just won't work if you've applied many hacks to the published branch. I strongly advise against this. Instead, just start over:

svn rm https://yoursvnserver/svn/project/branches/published \
-m "Deleteing published branch"
svn cp https://yoursvnserver/svn/project/trunk \
https://yoursvnserver/svn/project/branches/published \
-m "Branching published"

By nuking it and recopying it you can just svn up on your published branch and you'll have everything from trunk. For whatever reason, not removing it before copying it again caused us issues. I'd recommend this two phase approach.

Other things we learned in the course of this are the pros and cons of shared "stuff". We have at least 10 gigs of course content and a few other resources that don't need to be in the separate branches like our main trunk and published. We pulled those into their own repositories and keep them in shared directories so both installs can reference it. We also have a set of common build scripts between the two. This is both a good and a bad thing. It's good because it removes some duplication and it allows us to use a separate repo for these scripts (which is handy for some TC build configurations that only need the scripts, though I guess we could just checkout the scripts directory from trunk...) but it's bad because sometimes things will get out of sync. We'll make changes to the shared scripts, and fix the trunk, but it doesn't make sense or it's prohibitive to fix the published branch. You can see in the screen shot I posted our published branch is currently failing. This is likely why. I'd probably recommend keeping all build scripts branched so that you don't run into these sort of issues.

The next thing to worry about is the database. I mentioned that we use multiple databases on the build server. What I didn't mention is that we also use multiple databases on our dev machines. We usually have three. One for trunk, one for trunk tests and one for published. The trunk tests db is imported "light" so our tests run in 6 minutes instead of 14. The trunk db is a nearly full copy of the production db so we have data when we poke around the site on our dev machines. We have a ConnectionStrings.config that is generated from the database info you pass the build script. You can do something like: msbuild Default.msbuild /p:DatabaseName=published and it'd build with the appropriate connection string.

For web applications you also have to worry about IIS. We have two web applications configured in IIS. One for trunk and one for published. This allows us to easily switch between the two by just changing our port or vdir in our url. They have multiple virtual directories underneath them that point to our various shared directories.

I think that's most of the tips I can think of right now. Let me know if you have any questions about anything.

I've mentioned before how much I like TeamCity, but I didn't really talk about how we use it. Just recently Jacob completed some work on multiple build configurations that make our life much easier. I thought I'd go over them here to give you an idea of how we handle continuous integration here.

Continuous Integration configurations

• CI - Trunk - This is the CI configuration everyone has. This watches the trunk of our SVN repository and builds whenever it changes it will also run our database migrations against the CI trunk database. It has all our built assemblies as artifacts. The artifacts take up a lot of space so we don't keep them around that long.
• CI - Published - This is just like CI - Trunk, but it watches our published branch, which is where we put everything that we're about to publish to the live site. We keep two branches so that we can make quick fixes to the published site without having to publish new features we're working on. This has its own database that is migrated.
• Nightly - Trunk - This runs daily rather than watching our source control. It migrates a database on our production database server that is a copy of our live database. It also builds and deploys the trunk to a test address on our production servers. This allows our team in Korea and our stakeholders to see changes every day in a safe environment. The Nightly is also a big part of our localization story, which I'll save for another post.

Database build configurations

• Snapshot - This and the other db build configurations probably deserve their own post with more details, but I'll do my best to explain these briefly. The Snapshot build configuration takes a point in time snapshot of the database and packages it into a zip file. The zip file becomes a TeamCity artifact that other projects can depend on.
• Nightly/CI Trunk/CI Published Baseline -

  These configurations import database snapshots into the database they refer to. The only time we need to do this is if a bad migration runs, or we want to "refresh" the data inside the database.

  It is important to note that we do not run CI - Trunk on a complete snapshot of the live database. When we do, it greatly increases the build time because our integration tests run significantly slower in a real database. Instead, we import a "light" database which contains all of the tables, but only the data from our static tables. The users, records, and anything else that grows as we get more and more users are just left empty. This means that we have zero sample data for these things during our integration tests, so we rely heavily on Fluent Fixtures to set up sample data.

  The other two databases do run nearly complete copies of the live database (we exclude log tables basically), so we still get to test our migrations and our site on real data.

Utility build configurations

• StatSVN - Runs StatSVN on our codebase. Somewhat useful source statistics. Mostly use it to see growth and churn.
• Duplicate Finder - Haven't really done this much to be honest, but TeamCity has build configurations whose sole purpose is finding duplicate code.

I'm completely enamored with this set of configurations. It makes so many things so painless. We still have room for improvement, managing all of the configuration differences in the sites is difficult. We also lack a one click live publish ability. We still follow a manual script for that, which is error prone and dangerous.

With Mingle 1.1 came several great new features, including date fields. Now you can track the date that you complete tickets by adding a Date Done field (along with a Complete transition that sets the Date Done field to today) and locking the Status field to be editable only by transition.

This works great for newly completed cards, but what about all the cards you already have in your system? Sure you could go without burn-up charts and date stats for those cards, but what's the fun in that? 

Fortunately, Mingle tracks every card change in a history table. Each change in the history table has a date associated with it, so all we need to do is figure out how to extract the dates we care about. I must warn you, this is a little complicated, and I'm sure ThoughtWorks doesn't at all condone you mucking around in your Mingle database manually, so please please back up your database before attempting this and of course I'm not responsible for any damage you do. That said, here's how I was able to retroactively add dates for our two date fields: Date Done, and Date Published.

1. Back up your Mingle DB. Really.
2. You'll need to identify the field you use to track status. We use Status. We have Status of 'Not Done', 'Done', and 'Published'.
3. Then connect to your Mingle database and find the name of your cards table and your card_versions table. Our project is called "eleutian_speakeng" so our tables are "eleutian_speakeng_cards" and "eleutian_speakeng_card_versions".
4. Add the date fields you want to populate if you don't already have them. We have "Date Added", "Date Published" and "Date Done".
5. Figure out which fields in the two tables you identified map to your status and dates (this is usually as easy as prepending cp_ and box_caring your names. For us we have cp_status, cp_date_published, cp_date_done, cp_date_added.
6. Edit the following queries to add in your table/field names and values (these are the exact queries I ran, you'll need to change the red things):

   UPDATE eleutian_speakeng_cards SET cp_date_added =
   created_at UPDATE eleutian_speakeng_cards card SET card.cp_date_done =
   ( SELECT MAX(b.updated_at) FROM eleutian_speakeng_card_versions a
   INNER JOIN eleutian_speakeng_card_versions b ON a.number
   = b.number AND b.version=a.version+1 WHERE card.number = a.number AND (a.cp_status='Not
   Done' OR a.cp_status IS NULL) AND b.cp_status='Done' )
   WHERE card.cp_status = 'Done' UPDATE eleutian_speakeng_cards card
   SET card.cp_date_published = ( SELECT MAX(b.updated_at)
   FROM eleutian_speakeng_card_versions a INNER JOIN eleutian_speakeng_card_versions b
   ON a.number = b.number AND b.version=a.version+1 WHERE card.number = a.number AND
   (a.cp_status IN ('Done', 'Not Done')
   OR a.cp_status IS NULL) AND b.cp_status='Published' )
   WHERE card.cp_status = 'Published'

7. Once you've got that taken care of, go ahead and run the queries (you backed up right?) and you should be good to go.

So now that you've got your dates in your database, how do you get the cool burn up chart? Like this (mold to your project):

{{
   stack-bar-chart
   x-label-start: SELECT MIN('Date Added')
   x-label-end: Today
   x-label-step: 14
   chart-height: 600
   chart-width: 700
   plot-height: 500
   plot-width: 550
   conditions: Type IN (Bug, Story, Task)
   three-d: true
   cumulative: true
   series:
     - label: 'Not Done'
       color: #e6a800
       data: SELECT 'Date Added', COUNT(*)
       type: area
     - label: Done
       color: #1bcc00
       type: area
       data: SELECT 'Date Done', Count(*) WHERE 'Date Done' IS NOT NULL
     - label: Published
       color: #0079bf
       type: area
       data: SELECT 'Date Published', COUNT(*) WHERE 'Date Published' IS NOT NULL
}}

One of the first things we did when we got a dedicated development server was set up a continuous integration server. The natural choice at the time was CruiseControl.NET, so Jacob set off to get CC.NET installed and configured. I can't speak to that experience first hand, but I know it wasn't a fun one. Lots of XML hell and other non-fun issues. The end result wasn't too bad--it'd email us when builds failed with a log, and we could review logs on our CC.NET site. There was really nothing WOW about it--it got the job done. It was frustrating at times because the logs it spat out were difficult to visually parse; it was basically just a verbose msbuild log with a failure mixed in somewhere... and that was if we were lucky enough to get a text log and not have to filter through the build xml log. I'm sure there are some things we could have done to filter that log down, apply xslt to our build.xml to make it more readable, or configure things to be nicer, but I'm also sure it would have involved hard work and more XML hell.

Enter the free Professional Edition of TeamCity 3.0. We'd tried out TC briefly in the past and it seriously lacked in the .NET support arena. Now they tout support for msbuild (2.0 and 3.5), sln files from 2003-2008, and even a nifty .NET duplicate code finder. They also have some pretty slick support for NUnit which I'll get to in a moment.

I decided to give it a shot again, so I set up the TC server on our Ubuntu VM. Why there? Well that's where most of our server tools are: SVN, Mingle, FogBugz and now TC. But wait, aren't we a .NET shop? Yep. The build doesn't happen on our Ubuntu VM. See, TC is set up to have a server + build agents. A build agent is basically a machine that will check out code, do the build when the server tells it to, and report back results and artifacts to the build server. This way you can have multiple Build Agents--different Operating Systems, system configurations, physical locations, etc.

Installing both the Server and the Agent were relatively straight forward. There were a few annoyances with the Agent's configuration (like I couldn't get it to use a network drive as a working directory and it took some tweaking to get things to work with our directory structure,) but after a while I got things up and running.

Setting up a build configuration in Team City is an absolute breeze. You basically have a 7 step Q&A about your configuration:

1. General Settings - Name, Description, a few options and the build number format (we use our SVN revision #)
2. Version Control Settings - You can set up multiple repos to check out with a number of tools (SVN, CVS, Perforce, StarTeam, ClearCase). I'm sure it wouldn't be too difficult to write plugins for Mecurial or Git. You can also tell it where to check out relative to your working directory and whether or not you want it to check out to the agent or on the server and then have the agent download it.
3. Build Runner - Mainly .NET and Java stuff. No Rake yet, but it supports command line so you could just use that. With MSBuild you just specify your MSBuild file, the target you want to run, and any command line args you need. It's here that you specify your build artifacts as well. Build artifacts are kept along side your completed builds and easily accessible from the TC site.
4. Build Triggering - You can trigger based on VCS changes, schedule, other build configurations completing, or automatic retry.
5. Artifact dependencies - This makes it really easy to say you want Build A to use Build B's artifacts. For example, an installer configuration that will build an installer based on the last successful CI build.
6. Properties and environment variables - Self explanatory.
7. Agent requirements - Not all your agents can run all your build configurations necessarily. This will let you set requirements. You can set these based on environment variables, machine names, etc.

Once you get things set up, you get to see the really cool stuff. TeamCity is just packed full of nerdgasm features that just work out of the box. No need to scour the web for plugins, deal with XML, or anything like that. Things just work. For example, you get full status of the build while it is happening--you can see what MSBuild step the build is on, you can see the important messages in the Build Log (it filters them quite intelligently), you can even see what threads/processes are running. If you use their NUnit runner you can even see how many tests have passed/failed/been ignored.

That's not all you can see with their test runner though. You also get a full history of each test--how long each test took each time it was run, and if one fails you can see in what build it first failed, if it has been fixed yet, and you can even click to open it in your IDE if you have the Visual Studio plugin installed. The Tests tab even orders your tests by Duration so you have an idea which tests you may need to optimize.

Then there's the Statistics tab. This tab is a one stop shop for build health. You can see how long the build takes, how often it succeeds, how many tests you have, how many fail and even how big the artifacts are. You can see our build #s jump when we switched from a counter to SVN revision.

If there aren't enough features for you, don't worry, like with most JetBrains products you can extend them to your hearts content. That is if you can stomach the lack of API documentation (surprisingly, normal usage documentation is pretty good). One of our guys is working on a Campfire Notification plugin at the moment so we can get better build notifications in our Campfire. That's another post though.

All in all, we're very happy with TeamCity. It's just as free as CC.NET for a team of our size, it's much much easier to set up, and it has way more features. How could you go wrong? I'm sure its only a matter of time before we start to see rake runners, MBUnit test runners, and many other things to make TC even better. JetBrains has a winner here.

I just profiled one of our test assemblies (Unit tests only, nothing hitting the db). Mocking accounts for 196 seconds out of 357 seconds. The culprit is System.Reflection.Emit.TypeBuilder.CreateType(). This doesn't come as that much of a surprise to me, but still... is there a faster way to do this? Oh and yeah, the results of CreateType are cached so its only the first time you create a mock of a type that you take this hit, but still... that can really slow down TDD.

And no, I'm not saying we should stop mocking... just raising awareness.

I haven't posted in a while and decided to write a post about one of the little side projects I've worked on recently. I've been lurking around on the ALT.NET mailing list and one of the discussions I take time to keep up on is on Dependency Injection. Something I worked on a few weeks ago has some applications in that area and so I decided to see what others thought.

I was talking with Aaron several months ago about how many problems constructors in static languages cause. Ruby people are fortunate in that their constructors are much more flexible than their C# counterparts. Want something to be a singleton? Just return the same instance from the constructor! Lifecycle management and dependencies can be the responsibility of the constructor itself, rather than a function of a container.

Over the weekend a few weeks ago I wrote a library and MsBuild task that factors constructor calls out of code and into a pluggable factory system. You write code like this:

          public
          class EmailSender
{ publicvoid TellEveryone(string message)
{ TemplateRenderer renderer = new TemplateRenderer(); Console.WriteLine(renderer.Render(message));
} } publicclass EmailSenderFactory
: IObjectFactory<EmailSender> { public EmailSender
Create() { returnnew EmailSender();
} } EmailSender emailer = new EmailSender(); emailer.TellEveryone("Hello,
World!");

What the MsBuild task will do is this:

1. Load the target Assemblies using Mono.Cecil
2. Find implementations of IObjectFactory<T> and add them to the FactoryMap.
3. Find all instances of new T() for each of those factories and replace them with a call to the Factories.Create<T>(), ignoring calls inside of factories themselves.
4. Weave the FactoryMap (just the Factory Type and its Object Type) into the Assembly.

So during runtime we can use the FactoryMap that was serialized in step #4 to create the factories and use them to create instances as they're demanded. It is important to note that your objects need default constructors, even though they may never be called after the code is weaved. One can also replace the factory implementations with IoC backed versions, etc...

Why don't you just create a New.Instance<T> method and use that instead of new T() and save yourself the pain of weaving and having a task and all that, moron?

Good question! I mostly did this as an exercise in code weaving using Cecil. It's a great library, although testing code using it can be a little tedious. I'm tossing around some other projects that I'd love to give a shot and this was a good introduction. You could achieve the same thing using reflection to build your factory map and remember to use New.Instance<T>() instead of the new operator in your code. Granted, the manual approach plasters the concern all over the place and weaving keeps the original code free from that. Which may be an OK trade-off for the simplified process.

Another thing to consider, is that perhaps the weaving approach has its applications elsewhere? Use it specifically for creating domain classes to transparently provide domain services? Another idea I've been tossing around is if you're writing code for platforms where garbage collection isn't as performant (xbox for example) you may be able to transparently add object pooling and other patterns after the fact and not clutter up the original code.

I want to release the code anyway, but I'm tired of uploading zip files. All my future source releases will probably be via Google Code or some public svn repository. Stay tuned.... In the meantime, feel free to opine.

So everyone's been talking about the ALT.NET conference, Microsoft's take on MVC, and such, so I thought I'd briefly chime in with my thoughts. First of all, the ALT.NET conference rocked and I'm very much looking forward to the next one. Secondly, I must disclose that Scott Bellware paid me to say that ($1, signed) but I would have said it anyway.

OK, so then there's the whole MVC thing. This too was awesome and I should try and collect a signed dollar from Scott Guthrie. It's obvious he and the team working on MVC are doing their research. That said, as many of you know we're a MonoRail shop here. We've been using it heavily for about a year now and we've got a lot of code written on it. So what will the impending release of the MS MVC framework mean for us? What will it mean for MonoRail?

I can tell you that for us, it will very likely mean a week of exploration and quite possibly followed by a week or two of porting. That's right, it looked that good. Everything about it was done right or flexible enough to be made right so there really isn't any room to complain about it. MonoRail has more features at the moment, but the ones we use wouldn't be difficult to implement on top of MS MVC.

So what does this mean for MonoRail? I can't speak to that, but I will tell you what I would like for it to mean. What I'd like to see is MonoRail become more like Rails. I want to see something built on top of MS MVC that even more-so favors Convention over Configuration--including but not limited to generators and such. I want it to take it to the next level and be exactly what the community wants for a C# web platform. Dave Laribee says that "MonoRail will remain a viable option for smaller or more edgy shops." I think that's true, but I want to see it built on top of MS MVC.

Why throw away all of the framework code built into MonoRail? A few reasons:

1. Castle has already been experimenting with throwing most of it away and starting over anyway.
2. MS MVC will be built into the .NET Framework. This means  easier sells to big shops, and MonoRail would be just a free supplement rather than a replacement/paradigm shift, making it an easier sell.
3. MS MVC appears to be more modular. There is no massive Controller or ginormous SmartDispatcherController. You can even start with a one method interface and implement your controller however you want.
4. Routing.
5. It was built with testability in mind. MonoRail is now mostly testable, but it is not nearly as clean as it could be... or as MS MVC's testability looks.
6. We can probably all but throw away our codegenerator and use lambdas. We could reinvent this for MonoRail in .NET 3.5 but then we'd be... reinventing... it...

Whatever we decide to do when it comes out, we'll talk about our experiences so you can judge for yourself after we judge for ourselves how viable it will be to port from MonoRail to MS MVC.

First some code:

UserEntity user = New.User("bob").In(New.Company("ACME")).With(
New.PurchaseOf("ProductA") .WithAcademicSlot(1).FilledBy(New.EnrollmentIn(101).ThatIsCanceled)
.WithPlacementSlot(1).FilledBy(New.EnrollmentIn(1))); 

This code actually creates and saves (with NHibernate) about 12 or so entities. We can use code like this to set up one off sample data for tests in a way that's easy to read, understand and change. There is a decent amount of magic that goes into making this work and I wanted to talk about how I did it.

First we have a FixtureContext, which is just a hub for the DaoFactory, the current Session, and three helper classes, New, Current and Existing. New is the class responsible for the beginning of the syntax you see above. Each method on New returns a Creator. There's some magic in Creator, so here's the code:

          public
          class Creator<T>
: FixtureContextAware where T: class, new()
{ private T _creation; protected T
Creation { get { return _creation; } private set
{ if (Current.Get<T>() != value)
{ Current.Push(value); } _creation = value;
} } public Creator(IFixtureContext context) : base(context)
{ Creation = new T(); } public Creator(IFixtureContext
context, T creation) : base(context) { Creation = creation;
} publicstaticimplicitoperator T(Creator<T>
creator) { if (creator._creation == null) thrownew Exception(
String.Format("Creation of {0} is null, it probably shouldn't be.", typeof(T)));
creator.Current.Pop<T>(); return creator._creation;
} } 

The first thing is that Creator is a subclass of FixtureContextAware, which is just a helper base class that provides access to FixtureContext's children. Next there are a few references to Current which is simply a collection of stacks of entities so that Creators can refer to other entities that are being created so they don't have to be passed around. This is better explained with an example. In the beginning example you see New.EnrollmentIn(101). An enrollment requires a User to be created, so because there is a User in this creation context, we can do this:

          public CourseEnrollmentCreator(IFixtureContext
context, short number) : base(context)
{ Creation.User = Current.User;  Creation.Course = Existing.Course(number);
Creation.StartDate = DateTime.Now; Creation.EndDate = DateTime.Now.AddMonths(1); Session.Save(Creation);
} 

The next thing is that the creation itself is stored as Creation in the Creator. This can either be new'd up or can be passed in to the constructor.

The coolest part (at least in my opinion) is the implicit operator. This allows you do to do things like: UserEntity user = New.User().Foo(), where each of those methods returns a UserCreator, but at the end of all of it the Creator is implicitly cast to a UserEntity, the thing actually being created. This also serves as an excellent time to pop the entity from the Current stack.

Next we have the Existing class. This is essentially just a wrapper for your Daos/Repositories so you can fetch things that are already in your database (like Existing.Course(number) or Existing.User("bob")).

With this simple framework in place, the next step is to start writing your domain specific Creators. Here's an example:

          public
          class PurchaseCreator
: Creator<PurchasedProductEntity> { protected PurchaseCreator(IFixtureContext
context, PurchasedProductEntity creation) : base(context,
creation) { } public PurchaseCreator(IFixtureContext context, string productName)
: base(context) { Creation.Product = New.Product(productName); //
Initialize Purchase... } public PurchaseCreatorWithSlot
WithAcademicSlot(int credits) { // Create
and add slot...returnnew PurchaseCreatorWithSlot(Context, this,
slot); } public PurchaseCreatorWithSlot WithPlacementSlot(int credits)
{ // Create and add slot...returnnew PurchaseCreatorWithSlot(Context, this,
slot); } public PurchaseCreator WithSessions(int credits)
{ // Create and add sessions...returnthis;
} } publicclass PurchaseCreatorWithSlot
: PurchaseCreator { privatereadonly PurchasedCourseEnrollmentSlotEntity
_slot; public PurchaseCreatorWithSlot(IFixtureContext context,
PurchasedProductEntity creation, PurchasedCourseEnrollmentSlotEntity slot) : base(context,
creation) { _slot = slot; } public PurchaseCreatorWithSlot
FilledBy(CourseEnrollmentEntity enrollment) { // Fill slot... }
} 

Then we add a PurchaseOf(string productName) method to New that will create and return a new PurchaseCreator. We can also add a PurchaseOf(ProductEntity product) and pass a New.Product("Product") in instead. You can make it as granular or magic as you want. Also, Notice that WithAcademicSlot and WithPlacementSlot return a subclass of PurchaseCreator that adds another method. Using techniques like this you can make some very verbose and context sensitive fixtures.

We also make our HibernateTests base class FixtureContextAware so that we can use nice syntax in our tests.

Here is the source for the basic framework. Let me know what you think. 

James Kovacs replied to one of my many NHibernate Optimization Ramblings:

In the first example, how do you know that most customers are unimportant until you fetch them from the database? You have an additional problem that generally NHibernate sessions are short - especially in web apps or web services. So when do you reset your fetching strategy. What if one portion of your code uses different customer properties than another? The adaptive fetcher needs to do a lot of analysis of your post-fetch code paths or monitor the behaviour of the application as it executes. As it stands, NHibernate has a lot of options besides adaptive queries, which I believe are better including projections (since you as a programmer know the data you need) and lazy-loading of properties - both collections and objects. There are probably others. We're talking about saving milliseconds on DB queries when a round-trip to the DB is at least an order of magnitude greater. I personally feel that adaptive queries would require a lot of work for little gain. I call YAGNI.

This is probably my fault, but his first question tells me he doesn't quite understand what I'm trying to propose. It doesn't matter if customers are important or unimportant. Once the both code paths are hit and the strategy fully adapts, it is adapted and it will fetch a superset of fields that are required for that query in the context it is called. There's no reason to ever reset that strategy unless the code changes. 

Context is another important aspect of the adaptive queries, and I'm not sure how I'd implement it. At the moment I'm thinking that something along the line of scopes (nested or single level) so for each scope/query combination there would be a strategy. That's the answer to his second issue. The only analysis it needs to do is it needs to pay attention to what properties are hit on the entities it fetched by proxying that entity. That's it. No instrumentation, parsing, or any other crazy stuff.

          using (Query.Scope("Print
Customer Stuff")) { customers = LoadCustomers(); ... }

As for the YAGNI assertion, I understand why you'd call YAGNI on the 2-12ms standard savings I showed in my tests, but You Already Do Need It at times (we use projections for just this) it's just that this would be automatic and require less maintenance and you wouldn't have to choose to do it. It would be free savings and require less manual optimization. If someone further down your chain decides they need to log customer.Name, you don't have to climb back up, find the original query and add it there. With projections at least you'd know you'd need to add it, but you'd have to change the query and change your DTO (anonymous types will help with this... I guess).

My point is, You don't need an inversion of control container, it's just easier. You don't need auto mocking containers for tests, it's just easier and you don't have to change your code when you change your constructor. You don't even need Mocks, you could write those by hand too. Well, with adaptive queries you don't have to change your code when you decide to access another field... or even another collection....

You also have to look further than field adapting. There's the potential to adapt collection initialization as well. No more select N+1's for those devs that don't pay attention, they'd just go away like magic. And yes, I realize hand optimized queries will generally prevail, but adaptively optimized queries will be free.

Today, Jacob had another great idea for a use of adaptive queries. We often do this in our MonoRail actions:

          public
          void ShowCourseEnrollments([EntityParameter]
User user) { foreach (CourseEnrollment ce in user.CourseEnrollments)
{ // Do something with ce.Course.Number } }

This probably requires a bit of explanation. Basically, when someone goes to the url /Controller/ShowCourseEnrollments.rails?user=1, MR's databinding (and our EntityParameter binder) will do an NHibernate session.Load<User>(1). At this time, the db hasn't been hit. As soon as we start enumerating user.CourseEnrollments, we're select N+1ing. Furthermore, we could potentially be doing another fetch for ce.Course. The solution to this is to either change your mapping to always fetch these things (bad idea anyone?) or to do something like this:

user = UserDao.FetchUserWithEnrollments(user.Id);

Well, what if adaptive queries kicked in at the databind, and instead of adding that method to your dao, you just got what you needed? Sure, YAGNI, but You Are Gonna Want It... if I or someone ever implements it.

Ayende posted a great comment with some questions about adaptive fetching. Here are his questions and my responses:

Let us assume this:
customers = LoadCustomers();
for customer in customers:
if customer.IsImportant:
print customer.Birthday
else:
print customer.CurrentCharge
What would the adaptive fetching do in this case?
Assume that you have started with mostly unimportant customers and then moved to important customers?
The amount of queries that would be generated is prohibitive.

In this scenario, adaptive fetching would generate a query that pulled IsImportant and CurrentCharge for unimportant customers. As soon as a single Important customer ran through this code, the query would change to fetch IsImportant, CurrentCharge and Birthday. It would also immediately lazy load *all* missing properties from the original query for all customers originally queried, and continue to track accessed properties. That's only one additional query for each differing codepath, and that's only the first time its hit. From that point on, until the query was reset (version upgrade, app restart if it's not persisted, manually, etc), then you would have all you needed for all codepaths.

Another problem that you have here is that you do a query like:
"select u.Name, u.Email from Customer" and the query actually returns you Name,Email, Address, Photo.
That violates the law of least surprise fairly drastically.

I don't see adaptive queries having that syntax. I'm thinking more along the lines of "select ??? from customer"  or "select what  i need from customer", etc. Specifying what you're looking for puts you right back into projections. If you want to be specific, use projections.

Finally, I think that a much easier solution than trying to eek a few more milliseconds from a DB query is not to go to the DB at all. Utilize NH's caching abilities, and you'll get a significant performance benefit for little cost.

I agree that most of the time you'd get more benefit from caching than squeezing some time out of the db. I just think it gets us one step closer to making mapping between objects and the db more friendly to both sides of the map, and gives developers a tool that works automatically "for free". I'm sure it'd also make DBAs happier that their devs aren't just doing select * all the time.

Now, if you still want adaptive fetching, the best way to get it is to help build the HQL Parser, which would generate a human workable AST.

Agreed. I guess if we work on rewriting chunks of NHibernate the code would become manageable eh? So yeah, I'll stop blathering and try and start contributing.

Oren replied to my original post about features I feel that NHibernate is missing. I think he may have misinterpreted some of my wants so I'll run through and reply in order.

Lazy Field Initialization

Obviously grabbing each field as it was accessed would be ludicrous. Lazy field initialization is simply something that needs to be there in order for partial object queries to work properly. It's the same idea as deciding whether or not to fetch a child collection. You query for it if you need it, you don't if you don't, and if you end up using the child collection when you didn't fetch it, it will get lazy loaded. I'm of the opinion that lazy loads are a smell, and if you hit them in anything but a border case, you're doing something wrong and you should be fetching what you need. 

I'm fine with specifying defaults on fields (don't load Photo unless I ask for it explicitly), but Lazy Field Initialization really would shine in partial queries.

Partial object queries

UserSummaryDetails is not User. Let's say I have a ReminderService that has a SendMailTo method that takes a User and a message. If all that method needs is that User's name and email address, why should I allow NHibernate to query for the entire user? It's just wasteful. Furthermore, it'd be rather tedious to have multiple Value Objects like UserSummaryDetails in your codebase just to support the different scenarios you want.

If you add Lazy Field Initialization and real partial object queries to the mix, you'd be able to query for a group of Users that just have email and name populated, and if you happen to need address, it'd requery for all of the user's addresses. You can even take it further and requery for all of the fields missing from the original user query. NHibernate should also probably slap you on the wrist (by logging it). I think I'm going to find a way to start logging all lazy loads so that we can investigate them.

Using objects like UserSummaryDetails eliminates a good chunk of the usefulness of the domain. That is,  you can no longer use the methods on the User object itself or any domain services that would consume that object.

So really what I want is the syntax I mentioned in my original post, which would just reuse NHibernate's field access strategy to set the appropriate fields. Any fields that were not set at that time would be flagged for lazy loading. On flush, only those fields that were set would be compared. Combine this with Adaptive Fetching Strategies and you've got a very powerful, self optimizing and flexible query mechanism that leaves you free to use your Domain as you wish.

Read Only Queries

Maybe it would make sense to give two sessions to each Dao, one of them that handled read only queries and one that handled read write queries. That's a good idea, but I still think it's something that should be built in (Hibernate does it). 

Join Qualifiers

I don't remember what the query was, but there was a reporting query I was trying to do involving multiple left joins that I just couldn't get to work with HQL. I was able to do it in SQL no problem by qualifying one of the joins, but every attempt in HQL hit a wall. Good point about having to support multiple db's. It's still something I'd like to see eventually.

First I want to admit something somewhat embarrassing: I don't know enough about databases. Until coming here, I've always had a DBA that could handle that. I've started to realize now how important it is for all developers to have a much better understanding about databases than I do. So I picked up this book. I was really looking to better understand optimization, especially knowing when to create indexes and optimizing queries. Though the book only had a few chapters on the subject, I felt like it greatly increased my understanding on the subject.

A few months ago I wrote about Adaptive Fetching Strategies. At that time I had little knowledge about covering indexes and how they improve performance. Oh well, it's just more reason something like that should be implemented. Before we even get to that however, NHibernate needs to have a few features added to it in order to be useful in scenarios where performance is important.

Remember folks, SELECT * is bad. NHibernate is for effectively always doing a SELECT * when you're asking for an object when it comes to index coverage. Yes, it specifies columns so it doesn't have all the problems associated with SELECT *, but it is still decidedly less performant than querying for only what you want. Compound this with the extra overhead the unneeded columns add during a flush, and you've got a pretty compelling argument to only query for what you need.

OK, so you've decided that you only want to query for what you need and you're using NHibernate. Well, you can do that... kind of. Not much differently than you can if you just used ADO.NET and DataSets though. NHibernate doesn't support lazy field initialization. This means that if you query for only username and email address from your user table, you don't get back a User. You get back a List of object[]'s. Arguably a list of object[]'s is less functional than a DataSet. Combine this with the fact that you're querying using HQL, which has a subset of functionality, predictability, and therefore optimizability of real SQL, and you start to see a big hole in whole ORM thing... if you want to optimize your pages. Yes, HQL does make writing queries more pretty and more in the domain, but it would be nice if it supported things like "on".

Obviously optimizing too early is evil, but we've had several pages now where we've needed to optimize, and just resorted to querying for a table of values. No longer are we querying for objects, that's just not performant enough. Especially in display scenarios where you're not making changes to anything as NHibernate lacks the ability to do read-only queries, so you end up with that (very) expensive flush unless you change your flushing strategy to be manual (awkward) or you detach your objects from the session (also awkward).

So in short, I feel NHibernate (and any ORM for that matter) needs the following features to really be optimization friendly:

• Lazy field initialization
• Querying for partial objects: select u(Username, Email) from User u
• Read-only queries that do not get flushed.
• Join qualifiers (on in T-SQL)

And yeah, I know it's open source and I could just do it myself, but I have nightmares about that codebase, and I hardly have the time to implement such large features. All I have the time to do is complain and wish :)

There's a good back and forth going on about something I've been thinking about for quite a while. Jacob Proffitt is basically claiming that DI's primary benefit is mockability in unit tests and that we should all but ditch it in favor of using TypeMock to mock our tests. Meanwhile, Ayende and Nate Kohari have been defending DI with reasons like "getting low coupling between our objects" (Ayende) and "simply put, dependency injection makes your code easier to change" (Nate).

Well, I think I'm just going to have to agree with both of them... to an extent. I agree that DI promotes loose coupling, but I disagree that TypeMock is too powerful (even though I said just that in our podcast with Hanselman, I'm allowed to change my mind). I think that DI has its place, and is not a Silver Bullet. There have been a number of times when I was refactoring a class, pulling out a method object, or moving something to a a sub service (in my attempts to adhere to the Single Responsibility Principle) that I've questioned whether or not that new class warrants all of the following:

1. Having an interface.
2. Being added to the container and being injected.
3. Writing new tests for just that, even though tests were already passing and will continue to pass for its parent object with the same coverage %.
4. Being mocked out of the original tests.

The problem with doing #4 with a framework like Rhino Mocks is that it requires you to do #3 (obviously) as well as #1 & #2 . You can't mock unless your methods are virtual or you're interfaced and that mock is injected. With TypeMock I can do #3 and #4 without worrying about adding my new class to the container. So why not add it to the container? Well, because a great deal of the time You Aren't Gonna Need It. I think once one other class takes a dependency on that service you have enough justification to control its creation in one place by adding it to the container. However, a great deal of the time, these one off objects you create to increase readability and maintainability in your code just end up either changing the way you test your objects in that you're testing more than one class at a time, or you end up with an interface and constructor argument explosion solely so that you can mock them in tests. In situations like that, Jacob is right--the only real benefit is mockability. Maybe we should consider using something like TypeMock in these situations? Just because something is powerful doesn't mean its evil. We just need to exercise more caution and use it only in times its warranted.

That said, I've never actually used TypeMock and this is all purely conjecture based on what I've read about it. I just think that we can learn something from the Ruby guys and from people with the viewpoints of Eli and Jacob, as long as everyone realizes that neither sides of the camp is producing Silver Bullets.

Jacob posted about the AutoMockingContainer several months ago. At that time we didn't really use it, it was just kind of an implementation of an idea. Well, we've finally started using it in some side projects (Resharper.TestDrive for example), and I must say... wow. It is most definitely the way to instantiate your subject under test most of the time. Why?

1. It decouples your tests from your constructors. This means that if you have multiple TestFixtures for a class and you want to add a new service to your constructor, you don't have to change a thing in your tests.
2. It simplifies your tests. Things are just cleaner when you're not having to create all your mock services to inject into your subject under test.
3. It helps reinforce good mock usage. The default mock strategy is dynamic mocks. You can override that if you want to, but most tests should (in my opinion) be written with dynamic mocks. Like Dave talks about you only really want to set actual expectations on zero or one mock at a time. Everything else should be more stub-like.

I've started to use a base class for all my tests. Let's take a look at ReSharper.TestDrive's test base class:

          public
          abstract
          class AutoMockingTests
{ private MockRepository _mocks; private AutoMockingContainer
_container; protected MockRepository Mocks { get { return _mocks;
} } protected AutoMockingContainer Container { get { return _container;
} } [SetUp] publicvoid BaseSetup()
{ _mocks = new MockRepository(); _container = new AutoMockingContainer(_mocks);
_container.Initialize(); Setup(); } publicabstractvoid Setup(); public T
Create<T>() { return _container.Create<T>();
} public T Mock<T>() where T
: class { return _container.Get<T>();
} publicvoid Provide<TService,
TImplementation>() { _container.AddComponent(typeof(TImplementation).FullName, typeof(TService), typeof(TImplementation));
} publicvoid Provide<TService>(object instance)
{ _container.Kernel.AddComponentInstance(instance.GetType().FullName, typeof(TService),
instance); } } 

So what's a test look like with this base class? Let's borrow Dave's example.

          public
          class SearchPresenterTests
: AutoMockingTests { private SearchPresenter _presenter; private SearchResultDTO
_fakeResults; publicoverridevoid Setup()
{ this._fakeResults = new SearchResultDTO(); this._presenter
= Create<SearchPresenter>(); } [Test] publicvoid Can_search_for_customers_by_number_of_orders()
{ using (_mocks.Record()) { Expect .Call(Mock<ISearchService>().GetCustomersByOrderCount(42))
.Return(this._fakeResults); } using (_mocks.Playback())
{ _presenter.SearchByOrderCount(42); } } [Test] publicvoid Search_results_are_displayed_to_the_user()
{ using (_mocks.Record()) { mockView.SearchResults = _fakeResults;
SetupResult .For(Mock<ISearchService>().GetCustomersByOrderCount(42)) .Return(_fakeResults);
} using (_mocks.Playback()) { presenter.SearchByOrderCount(42);
} } } 

Not bad eh? You can do some more complicated things too. Let's say all your presenters take a hub service called PresenterServices. Rather than mocking it and its child services and setting up expectations for each of the children you can just use the real one and do this:

      Provide<IPresenterService>(Create<PresenterService>());
      this._presenter
= Create<SearchPresenter>();

Now you can refer to all your hub's child services with the Mock<T>() method.

Ok, so if you made it this far you probably want to check it out for yourself. Thanks to Ayende, the AMC it is now part of Rhino.Tools so you can check it out (svn co https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk rhino-tools)  and build it yourself or just grab the current trunk build with all the dependencies here. Hope Oren doesn't mind me building and linking this... ;)

Writing ReSharper.TestDrive was kind of an exercise in tiny classes for me. I didn't TDD the whole thing because so much of it was just experimenting with ReSharper's mostly undocumented API and EnvDTE, though I did TDD a good portion of it after my initial spike. After I got a working prototype implemented I spent a lot of time refactoring it into tiny classes that for the most part follow the Single responsibility principle.

As this is the most code I've ever thrown out into the public at any one time and it was a bit of an experiment for me, I wanted to take this chance to ask the community to review my code. If you have the time, feel free to look over the code and tell me what you think. Likes/dislikes/hates/loves anything is fair game--feel free to rip on it. Maybe we'll get some interesting discussion out of it.

Source

Note: You must have ReSharper 3.0.1 in order for this to work.

When you're doing TDD you'll create two classes every time you need one. You'll create one for the class itself and you'll create one for the tests for that class. ReSharper makes it a little bit easier by allowing you to write your tests and then alt+enter on your class under test to create it. Unfortunately it will create the class in your test project and not your project under test. It may actually create it in that same file (I don't remember) which means you have to Move to File. Then you have to drag it over to the project under test and/or change the namespace. Pretty obnoxious for something we have to do so often.

So... I decided to write a ReSharper plugin to do just that. It'll also create tests from a class under test (just in case you cheated and created your class first). Heck, it'll even create all the folders you need to.

This current version makes a few assumptions about your structure and it's not configurable at all unless you actually hit the code. Here are the assumptions it makes:

• The tests for Project.Foo live in Project.Foo.Tests.
• Test classes have the "Tests" suffix.
• Test classes live in the same namespace as the classes under test.
• The tests for ClassFoo are in ClassFooTests.

I lied when I said it wasn't configurable at all. After you've used it for the first time it will have created ReSharper file templates that you can edit to customize what is generated when you create a test or a class under test. Just go to ReSharper>Options>Templates>FileTemplates>User Templates>TestDrive.

To install it just extract it somewhere and run install.cmd, or just copy the dll to your %APPDATA%\JetBrains\ReSharper\v3.0\vs8.0\Plugins\Resharper.TestDrive (obviously you'll need ReSharper installed).

To use it, just have the cursor somewhere within a class that doesn't have a test, or a test that doesn't have a class under test and hit Alt+Enter, select Create X Tests... or create X... and hit enter. In order for the light bulb/alt+enter to show up it will need to be able to find an associated project to the one you're in (Sample.Project.Tests<->Sample.Project).

I've got more plans for this but I wanted to get it out there to see what you all thought. Oh, and in case you're wondering, Bunker is just a really light nearly feature-free IoC container that Jacob wrote in a day for another project we're working on.

Binaries
Source

So I recently started using the Early Access edition of ThoughtWorks' Mingle. Let me start out by saying I'm impressed. Mingle is a very clean, very powerful and most importantly, very flexible approach to project management. We all have our approach to managing our projects and Mingle allows you to handle many of those methods. I've spent a few days over the last week configuring our Mingle project to map to our newly developing process.  It hasn't been entirely smooth sailing, but it's slightly less than an R1 product so I won't complain... too much :) Here's a list of my thoughts thus far:

1. Installation - I've done an install on both Windows and Linux. Both were relatively painless. The Linux install documentation was missing a few steps but that has since been fixed. I wish that Mingle could run on IIS and/or Apache. It's a bit annoying that I have to run it on a separate port than my primary web server, though Jacob tells me we can proxy a port with Apache, so that'd be nice.
2. Creating a new project - The existing templates are nice to allow you to see what Mingle is capable of. I wouldn't recommend creating your real project using one of the existing templates as it leaves you with a lot of undeletable properties you don't need. Start out by creating three test projects, one using each of the three templates and play around with them until you know what you want to go into yours. Then create yours from a Blank Project.
3. Card properties - It's really nice to be able to specify exactly what properties you want to be on each of your cards. The property creation UI could use some help though, it'd be nice if we could specify the values we want at the same time we're creating the property--but that's just a minor nitpick.
4. Wiki - Mingle allows for you to create custom wiki pages that have nifty things like bar graphs and pie charts and tables. My biggest complaint about the wiki is lack of documentation. Not all of the samples in the documentation seem to work and the syntax is a little confusing... plus, if you type something wrong the error messages you get back are less than useless. Fortunately I've managed to get most of the things I want in our overview wiki, but it took much longer than it should have. Also, there's no way at the moment to do a burndown chart which would certainly be a nice thing to have for a lot of the agile methodologies out there.
5. List view - Mingle has some really simple filtering options for its two views. You can basically choose a value for each of your properties (or any) and add tags you'd like to filter by as well. Once you have a view you like, you can save that view. If you really like the view you can add it as a tab to the top for the whole team to see. Unfortunately there are some limitations: There's no way to give an OR for two property values and there's no way to specify that you only want to see cards with a property that has a null value. I'm hoping they will add these things eventually. There's also no way to specify "Current User" in the view... which makes views like "My Bugs" out of reach. Also, there's currently a max page size of 25, so if you want to do batch operations you can only do them 25 at a time. That's pretty annoying. In the meantime I can get *most* of my views the way I want them, but not all of them.
6. Grid view - OK, this is pretty cool. You can pick a property to group by, and pick a property to color by. Of course you can specify the same filters as you can in the list (so the same limitations). What's nice though, is you can drag those cards around into different values for that grouped property. You can move a Story Card from New to Open just by dragging it. Pretty slick if you ask me. This view allows you to make a number of cool views. You can create an Assignment view that lets you drag unassigned cards to ready and willing developers. You can create an Iteration planning view that allows you to drag cards around to different Iterations. Or even an estimation view so you can drag your cards to different story point values. If you need more detail on a card, you can always just click it. It'll pop up a nice little window with more information so you don't have to navigate away from the page. All in all pretty fancy. It would be nice if the lanes were colored... if you have a long list it'd be easier to tell where you're dragging to when you're at the bottom. Oh, and where's the sort? I should be able to sort the cards in the grid.
7. Transitions - These are cool too. These allow you to add buttons to cards that meet specific preconditions. Clicking that button will set the properties you specify in the transition. Pretty slick to kind of workflow your process. Unfortunately there are a few things missing from these as well. You can't specify "Current User" in either the preconditions or the set area. This means you can't do things like automatically set the Approved By field when something is Approved. You also can't say that only the user who a Card is Assigned To can Resolve it. Just adding that feature would make it so much more powerful. The other thing that is lacking is that the only way to "trigger" these transitions is to actually click on the transition button. This means that dragging things around your swim lanes won't trigger these. Yes, that complicates things but it'd be nice to have some sort of trigger criteria... or even a view that shows "transitionable" cards that you can drag to transition them. Obviously I'm rambling now, but I think this is a cool idea and can be expanded upon.
8. SVN Integration - Right now we use Trac as a Wiki and to explore our SVN revisions. Mingle's SVN integration looks pretty slick but is kind of broken. Take a look at this diff to the right. See all that white? Why is that white? It's not blank lines when you do a svn diff... where's my context? I don't know if this is a bug or what, but it's annoying. Other than that, Mingle's SVN integration is reasonable. I like the fact that you can define keywords so that when you add things like "#245" or "card 245" in your commit log it will automatically reference that commit with the specified card.
9. Support - Eh... It seems the best point of contact with support is either email (which I haven't had a high enough priority issue to try) or their forum. The forum is painfully slow most of the day (read: unusable, but who knows if that's a routing issue between me and them or just their forum server/software) and doesn't have a ton of activity. A few of the bugs I reported were acknowledged via email so that's good, but who knows how seriously the suggestions are taken. There's only one guy moderating the forum so I'm sure he's busy, but it would be nice to see a bit more activity and feedback.
10. Overall impressions - It's slick. It's flexible. It's... a little slow. Loading our Bug Board view just now took almost 5.71 seconds and 51 requests. Eek. Granted I'm not local right now, but it's not much faster when I'm on my Lan. That said, we're using it. We moved all our bugs off of FogBugz and we're going to give Mingle a shot for now.  It's free for the first 5 users, so why not?
11. Wish list -

• The greatest thing about FogBugz is its email integration. It can check a mail account you specify and automatically create tickets for messages in that inbox. You can reply to the senders of that mail via FogBugz interface and you can receive more correspondence through email from the original sender. It's pretty slick and great for support. Right now we're just using FogBugz for this purpose. To handle support requests. If something is upgraded to a bug we'll move it to Mingle... but the copy/paste operation will probably get tedious, so it'd be nice to have this functionality built into Mingle as well.
• I want to be able to show/hide properties based on another property such as Type. If my Type is Bug, I should see Bug Status and not Story Status. Right now all cards have all properties even if they aren't relevant. It's fine that they have them, because I could change the type, but I don't want to see them.
• I also want to create Backlogs--Priority Queues. Having just a property with a fixed # of #s for Priority is annoying at best. It's much more natural to keep things in a sorted order. I want to be able to create a new backlog with a specific filter and then drag my cards into an order that I want. I then want to be able to sort in that order. That way I can pop things off of that stack in that order and as new cards come in I can insert them. I'm very tempted to write this feature on my own...
• Triggers--I mentioned this before, but it's worth mentioning again. I'd like to be able to specify what happens when I drag a card from one lane to another in a Grid view. I'd also like to be able to gate that dragging... something can't be dragged to Ready for Development until it has an Estimate set. Now that I think more about it, I think the latter would be more useful. I want to be able to specify constraints on the Cards that will be enforced by all views and editing techniques.

Alright, that's more than enough rambling for now. I'd strongly urge you all to go take a look at Mingle. It's got a ton of potential and I think it's definitely headed in the right direction. Remember, it's free for Open Source and it's free for the first five users of a Commercial project.

Generally when I'm testing something that has dependencies my test fixture looks something like this:

  [TestFixture]
  publicclass FooTests
{ private MockRepository _mocks; private Foo
_foo; private IBar _bar; [SetUp] publicvoid Setup()
{ _mocks = new MockRepository(); _bar = _mocks.DynamicMock<IBar>();
_foo = new Foo(_bar); } [Test] publicvoid Test()
{ using (_mocks.Unordered()) { SetupResult.For(_bar.ProvideService()).Returns(1);
} _mocks.ReplayAll(); Assert.IsTrue(_foo.DoSomething()); _mocks.VerifyAll(); } } 

Granted, I'm starting to use our AutoMocking Container more and more, but that's not the point of this post. As an aside, Ayende has some more examples on its usage and has added it to Rhino.Tools.

Anyways, back to the subject at hand. The above works great if nothing really happens in your Foo constructor. But what happens if part of the constructor is to call a method on IBar? Well surely you could just move the construction to the Test method:

    [Test]
    publicvoid Test()
{ using (_mocks.Unordered()) { _bar.DoSomeSetup(); SetupResult.For(_bar.ProvideService()).Returns(1);
} _mocks.ReplayAll(); _foo = new FooTests(_bar); Assert.IsTrue(_foo.DoSomething());
_mocks.VerifyAll(); } 

That works, but what if you have more than one test? Well, you could just do the same thing in every test, but that's an annoying amount of repeated code that doesn't add any value. You can't simply Extract Method on it because you'll most likely need to setup other expectations for other scenarios you're testing. So... now I do this:

    [Test]
    publicvoid Test()
{ SetupMocks(delegate() { SetupResult.For(_bar.ProvideService()).Returns(1);
}); Assert.IsTrue(_foo.DoSomething()); _mocks.VerifyAll(); } publicvoid SetupMocks(Block
block) { using (_mocks.Unordered()) { _bar.DoSomeSetup(); if (block
!= null) block(); } _mocks.ReplayAll(); _foo = new FooTests(_bar);
} 

And this:

          public
          delegate
          void Block();

Funny what a little Ruby exposure will do to you...

Shortly after I posted my original EleutianControllerTests, Scott Bellware, Hamilton and myself chatted about the subject, and Hamilton decided to help out by making some of the previously internal methods public. Context still isn't settable directly however (maybe we should have him change that too...), so you still have to do a little bit of magic to get your context in there. There's actually more code to do this now then when I just set it w/ reflection, but it's arguably more "correct" and doesn't involve "reflection" and you can mock more (like logging and such). Anyways, here's the code:

          using System; using System.Collections; using System.Collections.Specialized; using System.IO; using System.ComponentModel.Design; using System.Security.Principal; using System.Web; using Castle.MonoRail.Framework; using Castle.MonoRail.Framework.Internal; using Castle.Core.Logging; using Castle.MonoRail.Framework.Services; using NUnit.Framework; using Rhino.Mocks; publicclass EleutianControllerTests
{ #region Constants privateconststring ApplicationPhysicalPath
= "Q:\\PhysicalPath"; #endregion#region Member
Data protectedstring _virtualDirectory
= String.Empty; protected MockRepository _mocks; protected IRailsEngineContext
_context; protected IRequest _request; protected IResponse
_response; protected IServerUtility _serverUtility; protected IDictionary
_session; protected Flash _flash; protected IViewEngineManager
_viewEngineManager; protected ControllerMetaDescriptor _descriptor; protected NameValueCollection
_parameters; #endregion#region Test
Setup and Teardown Methods [SetUp] publicvirtualvoid Setup()
{ _mocks = new MockRepository(); _viewEngineManager = _mocks.CreateMock<IViewEngineManager>();
_descriptor = _mocks.CreateMock<ControllerMetaDescriptor>(); _context = _mocks.CreateMock<MockRailsEngineContext>(_viewEngineManager,
_descriptor); _request = _mocks.DynamicMock<IRequest>(); _response = _mocks.DynamicMock<IResponse>();
_serverUtility = _mocks.DynamicMock<IServerUtility>(); _session = _mocks.DynamicMock<IDictionary>();
_flash = new Flash(); _parameters = new NameValueCollection();
} protectedvoid InitializeController(Controller
controller, string areaName, string controllerName, string actionName)
{ controller.InitializeControllerState(areaName, controllerName, actionName); controller.InitializeFieldsFromServiceProvider(_context);
InitializeRailsContext(areaName, controllerName, actionName); } protectedvoid InitializeRailsContext(string areaName, string controllerName, string actionName)
{ SetupResult.For(_context.UrlInfo).Return( new UrlInfo("eleutian.com", "www",
_virtualDirectory, "http", 80, Path.Combine(Path.Combine(areaName,
controllerName), actionName), areaName, controllerName, actionName, "rails"));
SetupResult.For(_context.Server).Return(_serverUtility); SetupResult.For(_context.Flash).Return(_flash);
SetupResult.For(_context.ApplicationPath).Return("/"); SetupResult.For(_context.Request).Return(_request);
SetupResult.For(_context.Response).Return(_response); SetupResult.For(_context.ApplicationPhysicalPath).Return(ApplicationPhysicalPath);
SetupResult.For(_request.Params).Return(_parameters); SetupResult.For(_context.Session).Return(_session);
} #endregion } publicabstractclass MockRailsEngineContext
: IRailsEngineContext { #region Member Data private IViewEngineManager
_viewEngineManager; private IControllerDescriptorProvider
_controllerDescriptorProvider; #endregion#region Properties publicabstractvoid Transfer(string path, bool preserveForm); publicabstractstring RequestType
{ get; } publicabstractstring Url
{ get; } publicabstractstring UrlReferrer
{ get; } publicabstract HttpContext
UnderlyingContext { get; } publicabstract NameValueCollection
Params { get; } publicabstract IDictionary
Session { get; } publicabstract IRequest
Request { get; } publicabstract IResponse
Response { get; } publicabstract ITrace
Trace { get; } publicabstract ICacheProvider
Cache { get; } publicabstract Flash
Flash { get; } publicabstract IPrincipal
CurrentUser { get; set; } publicabstract Exception
LastException { get; set; } publicabstractstring ApplicationPath
{ get; } publicabstractstring ApplicationPhysicalPath
{ get; } publicabstract UrlInfo
UrlInfo { get; } publicabstract IServerUtility
Server { get; } publicabstract IDictionary
Items { get; } publicabstract Controller
CurrentController { get; set; } #endregion#region Constructors public MockRailsEngineContext(IViewEngineManager
viewEngineManager, ControllerMetaDescriptor descriptor) { _viewEngineManager = viewEngineManager;
_controllerDescriptorProvider = new ControllerDescriptorProviderStub(descriptor);
} #endregion#region Methods publicabstractvoid AddService(Type
serviceType, object serviceInstance); publicabstractvoid AddService(Type
serviceType, object serviceInstance, bool promote); publicabstractvoid AddService(Type
serviceType, ServiceCreatorCallback callback); publicabstractvoid AddService(Type
serviceType, ServiceCreatorCallback callback, bool promote); publicabstractvoid RemoveService(Type
serviceType); publicabstractvoid RemoveService(Type
serviceType, bool promote); publicobject GetService(Type
serviceType) { if (typeof(IViewEngineManager).Equals(serviceType))
{ return _viewEngineManager; } elseif (typeof(IControllerDescriptorProvider).Equals(serviceType))
{ return _controllerDescriptorProvider; } elseif (typeof(ILoggerFactory).Equals(serviceType))
{ returnnull; } elseif (typeof(IUrlBuilder).Equals(serviceType))
{ returnnew DefaultUrlBuilder();
} returnnull; } #endregion#region Classes privateclass ControllerDescriptorProviderStub
: IControllerDescriptorProvider { private ControllerMetaDescriptor
_descriptor; public ControllerDescriptorProviderStub(ControllerMetaDescriptor
descriptor) { _descriptor = descriptor; } public ControllerMetaDescriptor
BuildDescriptor(Controller controller) { return _descriptor;
} public ControllerMetaDescriptor BuildDescriptor(Type controllerType)
{ return _descriptor; } publicvoid Service(IServiceProvider
provider) { } } #endregion } 

          using NUnit.Framework;
[TestFixture] publicclass OperatorExplicitTests
{ publicinterface IFoo { } publicsealedclass Foo
: IFoo { } publicclass Bar :
IFoo { private Foo _foo = new Foo(); publicstaticexplicitoperator Foo(Bar
bar) { return bar._foo; } } [Test] //
Passespublicvoid TestCastFromClass()
{ Bar bar = new Bar(); Foo foo = (Foo)bar; } [Test] //
Passespublicvoid TestCastFromInterfaceToNormal()
{ IFoo bar = new Bar(); Foo foo = (Foo)(Bar)bar; } [Test] //
Throws System.InvalidCastException: Unable to cast object of type 'Bar' to type 'Foo'.publicvoid TestCastFromInterface()
{ IFoo bar = new Bar(); Foo foo = (Foo)bar; } }

Ugh, see what happens when you try to be sneaky? Is this a bug? A limitation?

If you're curious why I care, we have a custom implentation of IDbCommand that wraps a SqlCommand and this code expects it to be a SqlCommand... no fooling it I guess :/

Update: Hamilton committed my patch, so if you're running off trunk you won't need to do this anymore. Thanks Hamilton!

Currently MonoRail uses ResourceSets wrapped up in an implementation of IResource to provide Resources to views. Unfortunately, ResourceSets do not cascade when it comes to resource resolution.  ResourceManager.GetResourceSet does have a flag called tryParents, but all that does is try less and less specific cultures until it finds a match. In other words, if you have two resource files:
Foo.ko.resx: defines A, B
Foo.resx: defines A, B, C

If you locale is ko-KR, calling RseourceManager.GetResourceSet will yield a ResourceSet that maps to Foo.ko.resx, so asking for B will work, but asking for C will not. A ResourceSet only knows about itself.

ResourceManagers on the other hand, are perfectly capable of handling this cascade, which is quite necessary in at least our localized app, as we do not want to have to define strings in all languages for everything. So with ResourceManagers, asking for A, B, and C all behave as expected, preferring the most specified culture and cascading down as necessary.

Below is an implementation of an IResourceFactory that spits out wrapped ResourceManagers instead of ResourceSets.

To use it you'll need to add this to your web.config:

          <
          monorail
          >
          <
          services
          >
          <
          service
          id
          ="ResourceFactory"
          type
          ="Eleutian.Shared.MonoRail.ResourceManagerFactory,
Eleutian.Shared"
          />
          </
          services
          >
          </
          monorail
          >
        

Source

I'm sure you've all heard that the best developers are lazy and/or dumb. I certainly agree with that. Also, you know that writing repetitive code and repeatedly following tedious steps is bad and a waste of time.

OK, so we know that those things are bad... but how do you identify them? Often tedious steps and repetitive code is taught as the way you do things... so you just do them in that way without asking questions. Other times, we just don't know that there is an easier way. We're developers--we're creative, smart, inventive, and we should be able to tell when something can and should be done in a better way. 

Let me give you an example of some code I came across some time ago:

          Public userstring AsString = "U000000"PrivateFunction GetUserIDStr(ByVal userid AsInteger) AsString'Returns
String:' User Info FileNameDim source AsString =
userid.ToString() 'Dim destination As Char() = {"U"c, "0"c, "0"c,
"0"c, "0"c, "0"c, "0"c}Dim destination AsString = Me.userstring Dim sourcelen AsInteger =
source.Length() Dim destindex AsInteger =
7 - sourcelen source.CopyTo(0, destination, destindex, sourcelen) Return destination End Function

Obviously there are several things... off... with this code. Let's discuss some of them. The first is the original Dim destination that is now commented out. This is an example of someone partially applying what I'm talking about. They realized that typing out that array was unnecessarily complicated so they did something about it. That's great, that's what we need to do. Unfortunately, they stopped there. I don't think we should stop there. We should look at the code, say, wow, this isn't really doing anything but formatting a number into a string. There has to be a better way to do this! In this case there certainly is... all of that code can be replaced with something along the lines of:

          Return
          String.Format('U{0:D06}',
userid)

Which is easier to read? Write? Maintain? The answer is obvious... even if you didn't know about String.Format, you should know when you're writing that code that there has to be a better way. Google is your friend.

What if there isn't a better way? Can you think of a better way? Ask yourself these questions:

• Are you going to be doing this more than a few times?
• Are other people on your team going to be doing it?
• Are you looking for a break from your normal work?

If the answer to any of those questions is yes, take some time to write or come up with a better way. You're a developer. You develop. Remember, you can write software for yourself and your teams that will make writing software more enjoyable and faster. And then, when you're done, share it! Share it with the world, make development easier for everyone.

I'll give you another example. I've already blogged about it, but it's relevant to this post so I'll rehash here. In order to localize a string in MonoRail you must do the following:

1. Create a new resx file.
2. Add a Resource attribute to your controller mapping the resx to a key in the PropertyBag.
3. For each string you want to localize, add a key/value pair to the resx file.
4. Replace the strings in your view template with your resource key.

Hm. Every controller? Every string? Talk about context switching. Not to mention the fact that you can't see the actual English string in your view template, so any modifications to the English string require the same context switching. It didn't take me long to decide that was far too tedious for myself and my team.

It probably took me 2-3 days overall to write both the ASP.NET preprocessor and adapt it to MonoRail/Brail. Will I ever get 2-3 whole days back? Who knows. Will my entire team in total? More likely. Does it save us countless context switches, speed up our development, and make localization trivial? Absolutely. So was it worth it? Absolutely.

And before you ask, yes I plan on taking my own advice and sharing it... eventually. Oh and keep in mind, this sort of thinking can and should be applied to everything you do, including but not limited to code, tools, and process.

In a previous post I talked about how we use automatically generated interfaces to wrap our PropertyBag's. You can also use this technique in your ViewComponents to clean up that code quite a lot. We used to have code like this:

          public
          class SomeComponent
: ViewComponent { publicoverridevoid Initialize()
{ base.Initialize(); User user = (User)this.ComponentParams["User"]; floatvalue = this.Service.CalculateThatValue(user); this.ComponentParams["SomeCalculatedValue"]
= value; } }

Now we can make an interface:

          public
          interface ISomeComponentView
{ User User { get; set; } float SomeCalculatedValue { get;
set; } } 

And ask the code we wrote for the PropertyBag to give us a hand in cleaning things up:

          public
          class SomeComponent
: ViewComponent { publicoverridevoid Initialize()
{ base.Initialize(); ISomeComponentView view = this.ViewFactory.ResolveView<ISomeComponentView>(this.ComponentParams); floatvalue = this.Service.CalculateThatValue(view.User);
view.SomeCalculatedValue = value; } }

Much better! If you're looking for an implementation of that ViewFactory service, Lee Henson tossed one together shortly after our post. He's also added some other, pretty nitfy features since then. Like the ability to specify a prefix with an attribute for the generated dictionary keys. As he mentions in his post, you can use it for anything (and probably should) that uses strings as keys into an IDictionary (Session, Flash, etc..). I'm planning on checking it in to CastleContrib soon, until then, grab it off the list. Thanks Lee!

Martin Fowler has a great post entitled Mocks Aren't Stubs. Go ahead and read/skim through that if you haven't. Of the two categories of TDDers he defines, I am definitely a mockist. That is, I almost always "use a mock for any object with interesting behavior". I do use Mocks and Stubs, but those stubs are generally just Mocks set up to be stubs (as it's easier than stubbing a class myself.) That said, I do have a few ground rules for when I write tests with Rhino Mocks that sort fall into the whole oneassertionper test topic and the mocks vs. stubs thing. Here they are:

1. Name TestMethods MethodOrPropertyName_Scenario_ExpectedResult. I stole this from someone, but I can't remember who. If you know what post that was, let me know so I can link it. An example is: CalculateCost_WhenProductIsNull_ThrowsException. I just think this makes your intent very clear and readable.
2. Never use _mocks.Ordered() unless you are actually testing the order in which something is called... and if you are, test only that!
3. Unless you're testing that something gets called once and only once (expensive method? caching?), use Repeat.Any(). Who cares if it gets called again?
4. Prefer DynamicMock over CreateMock (standard mocks). Here's an example. You're testing that your controller sets FirstName on a view. You write that test and implement the feature. Two days later you need to add EmailAddress to that view, so you write your test to ensure that it is added. You implement it and run your tests... now, if you used a standard mock, your original FirstName test would fail! With a DynamicMock however, you have no tests to "fix" (tests should rarely need to be fixed because you added something to the class that has no bearing on the originally tested scenario)
5. Don't use VerifyAll. What!?!? That's right, half the time I use Verify(someMock) and the other half I don't even Verify anything (as I can verify the result of a method called). Your tests should be complete enough that it shouldn't matter if ObjectA called ObjectB as long as ObjectA gives you the correct result.

Remember, Verification, Ordering, setting a fixed # of repeats, requiring every method/property to be "expected", etc, are all Assertions. I'm not steadfast on the whole one assertion per test thing, as sometimes a few assertions make sense. As long as you at least think about what your test would be named if you put every assertion in the method name of the test, I think that a lot of these rules would make more sense.... Would you rather diagnose a break in SomeMethod_WhenSomeObjectIsGreen_CallsFooTwiceThenCallsBarWithResultOfFoo
OnceThenSetsColorAndShapeAndResultOfFoo() or SomeMethod_WhenSomeObjectIsGreen_SetsColor()? :)

Roy Osherove brings up several good points with regards to the preached design methodology of old and the new testable design some of us have come to know and love lately.

I think that TDD really helps to eliminate a large number of these issues. If you test everything yourself, then inherently your API is testable. Unfortunately, as Jonathan Cogley points out, TDD is not yet mainstream.

A nice side effect of having a testable API or application is that often times your code is also extensible. The thing that blocks it from being fully testable and extensible are those darn sealed and internal keywords, and of course, not making things virtual that really should be. Even open source projects are guilty of not having testable or extensible enough APIs. Yes, Castle MonoRail provides AbstractMRTestCase, but that actually uses ASP.NET and is way more heavy than I like.

Here is our base class for Controller Tests. This allows you to unit test nearly every aspect of your controller, without ever hitting ASP.NET. Notice the lovely and necessary use of reflection? In order to mock the context, you'll want to call InitializeController and pass it the controller you're testing, but be sure to do it in your _mocks.Unordered block (we almost ALWAYS use mocks.Unordered... it makes tests more readable and ensures that you're tests aren't too tightly coupled with your implementation, but that's the subject for another post.)

          public
          class EleutianControllerTests
{ #region Constants privateconststring ApplicationPhysicalPath
= "Q:\\PhysicalPath"; #endregion#region Member
Data protectedstring _virtualDirectory
= String.Empty; protected MockRepository _mocks; protected IControllerServices
_controllerServices; protected IRailsEngineContext _context; protected IRequest
_request; protected IResponse _response; protected IServerUtility
_serverUtility; protected IDictionary _session; protected Flash
_flash; protected NameValueCollection _parameters; #endregion#region Test
Setup and Teardown Methods [SetUp] publicvirtualvoid Setup()
{ _mocks = new MockRepository(); _context = _mocks.CreateMock<IRailsEngineContext>();
_request = _mocks.DynamicMock<IRequest>(); _response = _mocks.DynamicMock<IResponse>();
_serverUtility = _mocks.DynamicMock<IServerUtility>(); _session = _mocks.DynamicMock<IDictionary>();
_flash = new Flash(); _parameters = new NameValueCollection();
} protectedvoid InitializeController(Controller
controller, string areaName, string controllerName, string actionName)
{ BindingFlags bindingFlags = BindingFlags.FlattenHierarchy | BindingFlags.Instance
| BindingFlags.NonPublic | BindingFlags.InvokeMethod; MethodInfo method = controller.GetType().GetMethod("InitializeControllerState",
bindingFlags); method.Invoke(controller, newobject[]
{ areaName, controllerName, actionName }); FieldInfo field = controller.GetType().GetField("context",
bindingFlags); field.SetValue(controller, _context); field = controller.GetType().GetField("serviceProvider",
bindingFlags); field.SetValue(controller, _context); InitializeRailsContext(areaName,
controllerName, actionName); } protectedvoid InitializeRailsContext(string areaName, string controllerName, string actionName)
{ Expect.Call(_context.UrlInfo).Return( new UrlInfo("eleutian.com", "www",
_virtualDirectory, "http", 80, Path.Combine(Path.Combine(areaName,
controllerName), actionName), areaName, controllerName, actionName, "rails")).Repeat.Any();
Expect.Call(_context.GetService(typeof(IUrlBuilder))).Return(new DefaultUrlBuilder()).Repeat.Any();
Expect.Call(_context.Server).Return(_serverUtility).Repeat.Any(); Expect.Call(_context.Flash).Return(_flash).Repeat.Any();
Expect.Call(_context.ApplicationPath).Return("/").Repeat.Any();
Expect.Call(_context.Request).Return(_request).Repeat.Any(); Expect.Call(_context.Response).Return(_response).Repeat.Any();
Expect.Call(_context.ApplicationPhysicalPath).Return(ApplicationPhysicalPath).Repeat.Any();
Expect.Call(_request.Params).Return(_parameters).Repeat.Any(); Expect.Call(_context.Session).Return(_session).Repeat.Any();
} #endregion } 

Oh, and back to the original point of the post. Please, please don't mark things internal or sealed unless you have a very good reason to do it. And no, I don't think that "We can't afford to support it" is a good enough reason. Also, "We're afraid the user might break something" is DEFINITELY not a good enough reason. We know what we're getting into when we extend APIs... we're all developers here.

I've been writing a lot of tests lately because our code coverage isn't up to where we'd like it. NCover+NCoverExplorer is a pretty awesome and while it does have its quirks it has been incredibly useful. A lot of my adventures in writing tests is creating tons of RhinoMocks so that I can pass them to constructors and that sort of thing. So I got a strange idea, and I'm not sure how I feel about it necessarily and figured I'd propose it to all of you out there and get your thoughts.

Basically, 99% of the time in a services unit test, all the interfaces passed to the service will be mocks, so we end up with lots of functions that look like this:

[SetUp]
publicvoid Setup()
{ _service1 = _mocks.CreateMock<IService1>(); _service2 = _mocks.CreateMock<IService2>();
_service3 = _mocks.CreateMock<IService3>(); _serviceWeAreTesting = new DefaultServiceWeAreTesting(_service1,
_service2, _service3); }

If we do this a lot for DefaultServiceWeAreTesting, it's often refactored to a single location. All in all, it can be very repetitive to create all the mocks. So, as an experiment I decided to leverage the power of the IoC container, in our case Windsor, to take care of a lot of the mundane for me. In the end I end up with this code:

[SetUp]
publicvoid Setup()
{ _mocks = new MockRepository(); _container = new AutoMockingContainer(_mocks);
_service = _container.Create<DefaultServiceWeAreTesting>(); }

AutoMockingContainer is simply a WindsorContainer with a custom facility and dependency resolver that supplies a RhinoMock for any interface that is resolved. We've also moved the setup code into a base class AutoMockingTests that has the container and mock repository. We can then write code that uses the mocks from the container:

[Test]
publicvoid DoWork_Always_AsksOtherServices()
{ using (_mocks.Unordered()) { _container.Get<Service1>().DoWork();
_container.Get<Service2>().DoWork(); _container.Get<Service3>().DoWork();
} _mocks.ReplayAll(); _service.DoWork(); _mocks.VerifyAll(); }

Of course, you don't have to always do the Get call on the container, you can do that in the Setup and use member variables, etc... the point is, the mocked services are created for us. We can also mark other types so that they aren't tested, and take advantage of the IoC and injection that we use in our application to speed up writing and maintaining tests. The implementation I've uploaded allows you to associate a particular strategy with service dependencies. They are:

• StubbedStrategy: A mock will be created, then for each property a GetValue expectation (with Repeat.Any) will be added to return a value for that property. The value will be retrieved like any other dependency (it's strategy will be gotten, and the value from that)
• DynamicStrategy (default): A DynamicMock will be created for the dependency.
• StandardStrategy: A standard mock from CreateMock.
• NonMockedStrategy: Automatically set for any service that is registered normally with the container - a standard container resolve.

So, pros and cons? To get things started:

Pros

1. Can be easier to maintain and write tests. Adding a dependency or changing the constructor breaks tests in ways that the production environment can usually handle just fine.
2. Automatic testing the services construction via the IoC container.

Cons

1. Speed/peformance? Does making the container such an integral part of the test fixtures hurt performance? Setup has to be longer when we're creating the container the way we are. Does this matter? Only as long as the time saved when writing tests is larger than the time it takes to run them, which I'm sure is the case...

What do you think? So far we really like the idea, or at least think it's interesting. Here are the sources:

Source and Binaries

I'm pleased to announce that I've committed Castle.Tools.CodeGenerator into the CastleContrib repository. What's in trunk also includes some patches posted on the mailing list by Chris Ortman and some other suggestions. It also includes some bug fixes I made. We've deleted the code generator from our repository, so any changes we make will be to the castle repository. Eleutian.Tools.CodeGenerator is no more, long live Castle.Tools.CodeGenerator!

I spent yesterday and today refactoring the code for the Controller Action/View map generator tool. I made some improvements, wrote some tests and I'm pleased to announce the first release. I saw Brian had implemented his as an MsBuild task and I liked that idea, so that's how ours runs now. First, things aren't as "drop in and go" as I would like because it's still evolving in and around our, already large, code base. It's my hope that over time the tool evolves as peoples needs change, etc... we can add some more configuration, that sort of thing. I'm more than willing to hear suggestions and such. Anway, here we go...

So in order to get yourself up and running, you'll need to do a few things. First, you'll need to add the task to your MsBuild. Simply open your csproj and add the following:

          <
          UsingTask
          TaskName
          ="Eleutian.Tools.CodeGenerator.MsBuild.GenerateMonoRailSiteTreeTask"
          AssemblyFile
          ="Eleutian.Tools.CodeGenerator.dll"
          />
          <
          ItemGroup
          >
           <
          ViewSources
          Include
          ="../YourViewsDirectory/**/*.brail"
          >
           <
          InProject
          >false</InProject> </ViewSources></ItemGroup><ItemGroup> <ControllerSourcesInclude="Controllers/**/*.cs"> <InProject>false</InProject> </ControllerSources></ItemGroup><TargetName="BeforeBuild"Inputs="@(Compile)"Outputs="$(ProjectDir)\SiteMap.generated.cs"> <GenerateMonoRailSiteTreeTaskFile="SiteMap.generated.cs"Namespace="YourNamespace.SiteMap"ControllerSources="@(ControllerSources)"ViewSources="@(ViewSources)"> </GenerateMonoRailSiteTreeTask></Target>

You'll notice a few things in here. ViewSources is just the collection of view files (be it .vm or .brail, etc..). It will use the paths of those files to add the View nodes into the map. ControllerSources is the C# source files for your controllers only, specifying this helps speed up parsing. I'll get to why in a bit. And for the Sources attribute on the task you should specify all the sources in the assembly, which @(Compile) works great for.

With the task added, you should be able to build and have a SiteMap.generated.cs file, now you'll need to tweak your "base" Controller class. If you're like us, you have a Controller class that you made yourself that all of your Controller's inherit from. In that class you'll need to add some code like the following:

          private ICodeGeneratorServices _services; public ICodeGeneratorServices
CodeGeneratorServices { get { return _services; } } public RootAreaNode
Site { get { returnnew RootAreaNode(this.ControllerServices);
} } protectedvirtualvoid PerformGeneratedInitialize()
{ _services = new DefaultCodeGeneratorServices( new DefaultControllerReferenceFactory(), new AspDotNetRedirectService()
); _services.Controller = this; } 

First is the member variable, _services. You can do this however you like, but it's consumed by the ControllerAction/ViewReference classes to do various likes. CodeGeneratorServices is a property the partial controller code uses to create the MyActions and MyViews node instances. Site is just an easy way to get the top, root level node. PerformGeneratorInitialize is overridden in the partial controller classes to add the MyViews and MyActions nodes to the PropertyBag so they are available in the views. So there you go. If I'm not missing anything, that should do the trick. Let me know if I did and I'll append to this post.

Oh, the reason for specifying the ControllerSources is to cut down on the number of classes/types we visit when generating the internal "tree" that the source code is generated from. At first glance it seems like you should just be able to parse the ControllerSources only. We coudln't really do that because we needed to gather information on the other types in the assembly so we'd be able to use them in the arguments of our actions, etc... 

I have to stress that the code is relatively new, having undergone a major refactor to isolate it from the rest of our project. I make no promises that I won't have to upload a new copy, with a fix. :)

Source and Binaries

Hello everyone. I just wanted to let those who responded to the string literal posts know what was "going on". Basically, we're still trying to find a way that we can release the source to some of our tools. I apologize for dragging my feet. I manage to keep pretty busy. Heh.

I was catching up on the castle-project's mailing list and found this post by Lee Henson. He's tossed together an implementation of a PropertyBag wrapper generator and posted the source. It's very similar to our approach. One main difference is that we do our generation at runtime so we don't have to generate and reference another assembly. We have an IViewFactory interface and a PropertyBagViewFactory implementation that hands them out. In tests we have an IViewFactory that pulls the views out of the MockRepository.

Incidentally, our code that does this lies with some other code for generating Control.Invoke proxies for our System.Windows.Forms view interfaces. It seems we're not the only people who do that particular type of generation. Rüdiger Klaehn has an article here about it. I strongly suggest reading it if you do any kind of SWF work.

In the thread I found a link to Brian Romanko's post about his implementation of the controller action/view SiteMap, as well as the PropertyBag wrapper. So just in case anybody gets impatient they can find something to tinker with over there. While his implementation is different from ours, the end result is very similar. I like his idea of generating a property for actions to refer to them without parameters.

I mentioned that for the SiteMap code generation we used CodeDom. CodeDom is great and means we don't have to use StringBuilder to construct C#. It also abstracts the language away. For those who are interested in this kind of code inspection/generation, I strongly suggest taking a look at N Refactory, it's a great library for parsing C#/VB.NET source. It's what we use and I've been incredibly happy with it. The only real hurdle when doing that kind or work is type resolution. I'll try and make a post about that in the near future.

Hosted on Zooomr

1 3007WFP + 2 2007FP = 4960x1600

Need I say more?

So I was recently at a good friend's birthday gig. He's actually my old lead at Microsoft. Anyways, some of our friends that are still at Microsoft were at the party and I got a chance to talk to one of them for a while about various things... primarily open source, TDD, Inversion of Control and Mock objects. He was interested in Rhino Mocks and wanted me to email him about it. Instead of just doing that I threw together a good sized email. Here it is (slightly modified):

Good to see you again. As we talked about, there has been quite a shift in the way we write programs... that is a shift towards a much more testable, more maintainable type of programming. I know there are teams at Microsoft that have embraced recent changes... some have gone agile, most use some form of continuous integration, and some have written Inversion of Control containers (the Composite UI Application Block by the patterns & practices group has a container in it), but I'm sure most teams aren't employing all of these practices and could benefit from at least some of them.

In a number of teams, I think that there are a lot of improvements that can be made... even without shipping anything that's open source.

Firstly, you should take another serious look at Test Driven Development. I've attached an interesting study on TDD, and you may want to skim the MS Press book on the subject.

Also, the following blogs have some real good info on it:
Jeremy D. Miller's TDD Posts
Ayende's TDD Posts

A big part of TDD and Unit Testing in general is being able to remove not only your ephemeral dependencies, but also the rest of your dependencies. That way you know, when something fails, exactly what class caused the failure... it's the class being tested. In order to get rid of the dependencies, you need to replace them. In order to replace them, you need two things. The first is a replacement. The second is a method in which to inject the replacement. Mocks and stubs can handle the first task. I mentioned that we use Rhino Mocks:

Ayende's Rhino Mocks Posts

The library is great, it makes for very readable code and it's pretty darn flexible.

The second item can be a bit more complicated. The thing you usually see when class Foo depends on class Bar is this:

          class Foo { private Bar
_bar = new Bar(); publicstring DoStuff()
{ return _bar.DoSomeOtherStuff() ? "yes" : "no" }
} 

Now if you're going to test Foo, you'll also be testing Bar. You can't avoid that the way it's written. Now, it's good to test Foo talking to Bar eventually, but that's what integration tests are for... not Unit tests. So what do you do? This:

          interface IBar { bool DoSomeOtherStuff();
} class Foo { private IBar _bar; public Foo(IBar
bar) { _bar = bar; } publicstring DoStuff()
{ return _bar.DoSomeOtherStuff() ? "yes" : "no" }
} 

Subtle difference, but this allows you to throw any implementation of IBar (including a mock) into Foo. That allows you to write a test like this:

[Test]
void DoStuff_WhenBarReturnsTrue_ReturnsYes()
{ MockRepository mocks = new MockRepository(); IBar bar
= mocks.CreateMock<IBar>(); Foo foo = new Foo(bar);
Expect.Call(bar.DoSomeOtherStuff()).Returns(true); mocks.ReplayAll();
Assert.Equals("yes", foo.DoStuff()); } 

Now even if Bar changes, or Bar doesn't even exist, this test will still pass.

Here's the definition from Martin Fowler of Dependency Injection/Inversion of Control

Unfortunately, real programs are a lot more complicated than just one class depending on another... dependency chains are generally pretty deep, and one class can depend on 5 classes, each of which depends on 2, each of which has a different lifetime... per web request, transient, singleton, etc. It would be quite a pain if you had to instantiate everything like this:
Foo foo = new Foo(new Bar(new Blah(), Yadda.Instance));

Fortunately, it's not terribly complicated to write a Container that can handle all of this for you... so all you do is something like:
Foo foo = container.Resolve<Foo>();

There are several:

• The CAB contains one
• Castle Windsor
• Spring.NET

And then I went on to mention how long this mail was getting and that I was going to post it to this blog.

It amazes me how often developers lack fundamental competencies. Things that every developer should at LEAST know about, somewhat understand and know the capabilities of (i.e. when they're presented with a problem that is easily solvable using something such as... oh, regular expressions, they can at least google the steps to a solution.) What I'm trying to say is:

Understand and make use of regular expressions whenever it is appropriate.

Unfortunately, if you're reading this blog, you probably read several other blogs, so you've already been exposed to regex's. If that's the case, the tip for you is:

Think of more ways you can use regular expressions, understand them even more, oh and tell a friend/coworker who doesn't subscribe to 30 dev blogs and doesn't understand/make use of regular expressions about them.

There are several resources for regular expressions.

Roy Osherove has come up with some pretty killer tools for regex:

• Regulazy
• The Regulator
• Regex Visualizer Kit

What do you do with them? Well, there are tons of uses for them, but here's a quick list of some of the basic things they're used for:

• Find things - Duh.
• Replace things - tons of cool stuff you can do here with and without capture groups. Here's a naive example:

  Foo bar
  Blah yadda
  Etc etc
  //
  search: (\w*) (\w*) replace: \1 \2 = new \1();// becomes: Foo
  bar = new Foo(); Blah yadda = new Blah();
  Etc etc = new Etc(); 

• Parse things - obviously we love to parsethings.

I've seen several people say the following when talking about TestDriven.NET: "It's so easy, just right click, and click run tests!" Maybe I'm just too lazy, but what's easy about moving my hand to the mouse, right clicking, finding the appropriate menu item and clicking it?

Bind a key to Run Test(s) and Run Test(s) with Debugger (I use Ctrl+Shift+R and Ctrl+Shift+D)

Just look for TestDriven.NET.RunTests and TestDriven.NET.Debugger in your keyboard settings. I personally use Resharper's Unit Testing feature (except in our 32bit apps on our x64 machines... they're still fixing that bug), but it's all the same. Bind a key to it. Real easy to finish up a test, hit Ctrl+Shift+R, and away you go. No arm movement required!

I've mentioned several tools that we use here, many of which cost money.  We're very lucky here that we can have most of the tools that we want, I know it pains the check writers--"What? Another $300s per dev?!?!" but thankfully they understand that it helps us immensely. I can't help but notice that occasionally people will mention on their blogs that they really like a tool, but that their company won't buy it for them. I think that usually, that shows a bit of shortsightedness in their management.

Developers are expensive and impatient. Good developers are often even more expensive and even more impatient. Tools help developers write more code faster, better, and with less distraction. We'll use ReSharper as an example to try and calculate true cost of the tool.

Let's say a developer's salary is $60,000 per year, that's about $240/day, or $30/hr. Say you build 10 times in an hour, half those times, you accidently typo'd something so you have to rebuild. We'll say fixing/rebuilding costs you 2 minutes per hour. That's 16 minutes per day or $8/day, $40/week, or about $2000/year. All for losing 2 minutes per hour. It's worse than that too, because 2 minutes is a gross exaageration, and that 2 minutes is during a developer's most productive time... the time they actually spend producing.

Now what if, for $300 you could have something that would warn you of impending build errors, so that you could fix them before you actually built? What if it had keybindings (I use Ctrl+Shift+N and Ctrl+Shift+P) to skip to the next error so you can quickly correct it? What if it saved you not only those 2 minutes per hour, but also gave you several other nifty features that saved you time with navigating, formatting, and several other things. Would you spend $300 to save $2000 per year? I would hope the answer is yes. Many other tools share this same productivity boost to cost ratio.

Does this mean developers should have carte blanche for tools? I don't think so. There still needs to be some filter in place, some time for evaluation, and someone who is in tune with both a developer's need for a tool and the company's need not to spend money senselessly, but please, managers, seriously consider requests for tools.

This goes hand in hand with the first tip, so I figured I should post it now.

Get Gaston Milano's Cool Commands 4.0 and bind a key to Collapse All Projects (I use Ctrl+Alt+C)

There are plenty of other useful gems in CoolCommands (e.g. copy/paste project reference is very useful), but the one I use several times a day is Collapse All Projects. If you've got 40 projects, collapsing them all makes selecting the 36 projects you want to unload much easier.

I don't like waiting for things. I don't like typing the same thing over and over again for days, weeks or even months on end. I do as much as I can to speed my production of code up. I want the bottleneck to be in my mind, not in my fingers or my cpu. I figured I'd share some of the things I've learned along the way. Hopefully, a few of the tips will grab your interest and make coding just a little bit less tedious for you. So without further blathering, onto the first tip.

Bind keys to Unload Project and Reload Project (I use Ctrl+Alt+U and Ctrl+Alt+R) and liberally unload projects you aren't mucking with.

This may not apply to you, but here at Eleutian we have about 40 projects to build. Client, server, tools, shared libraries, generators, preprocessors, etc and of course tests for all of them. If you have all 40 projects open, just the dirty check during a build can take up a good amount of time. Generally you're only working on a few projects at a time, so go ahead and unload the rest (you can shift and ctrl select multiple projects to unload or reload). Every build you do (if you're doing TDD, you're dong several) will take significantly less time. Less time between build/test runs is a huge win. Adding the keybinding just saves you from fishing through the 100 item project context menu.

As promised, here's the plugin I was talking about and the Rhino Mocks templates.

Rhino Mocks Templates - Import these in your Template config.

Plugin - Drop this in your "%PROGRAMFILES%\Developer Express Inc\DXCore for Visual Studio .NET\2.0\Bin\Plugins" Oh, and yeah I know it's named after only one of the commands in there, but I was too lazy after I added the other commands to rename the project. You'll see the new commands in the Template configuration in the Command dropdown.

Plugin Source - I know, not the source you want from us right now and it's pretty ugly, but it's a start, right?

I mentioned before that we love templates in CodeRush and that they're incredibly customizable. I wanted to give a few examples of that and share one of the plugins I wrote for it.

We use Ayende's Rhino Mocks quite a bit. We're also lazy, so I came up with a set of templates for it:

• tfm - Expands to a TestFixture that includes a MockRepository already.
• scm/sdm - Takes whatever is in your clipboard and expands to this:

  someClass = _mocks.CreateMock<SomeClass>();

• =cm/=dm - Similar to scm/sdm, but for when you don't have anything in your clipboard
• mu/mo - Creates a using(_mocks.[Un]ordered()) block
• mra - ReplayAll
• mv/mva - Verify or VerifyAll
• ec - Expect.Call().Return();

One thing I noticed while I was using these is that sometimes I wanted to use them after I'd already written some code that would be in the expansion... for example, say I've already got a class called SomeClassTests but I want to add the TestFixture attribute, add the MockRepository instance variable, etc. Before I had to delete the class and do a tfm on a blank slate. Instead, I spent a few minutes writing a template command plugin that allows you to add an attribute to the class your cursor is in. That enabled me to do what you see in the video below.

Also, say I've already typed the method I was going to set a rhino expectation on. Normally, I'd just have to go to the beginning of the line, type Expect.Call(, go to the end of the line, type the rest. So to solve this, I wrote a few commands: DeleteSemicolon (this one seems a bit buggy w/ the latest CodeRush), GotoBeginningOfLine, and GotoEndOfLine. Now ec, ae, an, ann, etc can all be written to add code around code I've already written as you'll see in the video below.

Bear with me on this video, it's my first attempt at something like this. If anyone can suggest something better than YouTube and a screen recorder for stuff like this that's still free, I'd appreciate it. I don't like being limited to 320x240.

Also, the astute will notice that I'm not running Resharper on this machine. This is my home machine and once again I'm not quite sure about the stability of it (it likes to crash every time I close VS, it breaks some autocomplete scenarios, etc). There are some autocomplete issues in this video, but i think that's just because I had multiple classes named the same thing in this project.

I tried to go slowly so that you can see the templates before I expand them so that hopefully you can get a feel as to how easy it is to write code when you've got templates this powerful. I'm going to upload the source for the plugins as well as my Rhino Mocks templates a bit later today.

I figured I might as well continue on the string literal kick I started with my last post and talk about another situation where we've eliminated string literals. Take the following code from inside a MonoRail action method:

PropertyBag["User"] = ourUser; PropertyBag["TwoStates"]
= newstring[] { "WA", "CA" };
PropertyBag["IsAdmin"] = true;

String literals, used as keys into dictionaries carry a cetain degree of code smell (for us) and we try to avoid them. It reminds me too much code that does something similar, but in the opposite direction:

          int id = Int32.Parse(this.Params["id"])

Thankfully, this kind of code is eliminated when using MonoRail and its SmartDispatchController. We found ourselves thinking of how the same code would look in a SWF application. We would be populating views, only those views would be interfaces that the various forms/controls implemented. Well, this is exactly what we wanted in MonoRail, to wrap the PropertyBag with an interface!

After a few hours playing with Reflection.Emit, I had a code generator that would take an interface:

          public
          interface IEditMyProfileView
{ string Name { get; set; } DateTime Birthday { get; set;
} IList<TimeZone> TimeZones { get; set; } } 

And produce a class like the following:

          public
          class EditMyProfileViewPropertyBagManipulator
: IEditMyProfileView { private IDictionary _bag; public EditMyProfileViewPropertyBagManipulator(IDictionary
bag) { _bag = bag; } publicstring Name
{ get { return (string)_bag["Name"];
} set { _bag["Name"] = value; }
} public DateTime Birthday { get { return (DateTime)_bag["Birthday"];
} set { _bag["Birthday"] = value;
} } public IList<TimeZone> TimeZones { get { return (IList<TimeZone>)_bag["TimeZones"];
} set { _bag["TimeZones"] = value;
} } } 

This has the advantage of keeping our interactions with the PropertyBag as type safe as they can be. Changing the interface, breaks the build. Where as changing the type of a value inserted into the PropertyBag will (hopefully) only break tests if even that. This is another example of us trying to turn run-time failures into compile-time failures.

This kind of thing also makes tests more elegant. Instead of:

Assert.Equals("Jacob", PropertyBag["Name"]);

In our controller tests, we can continue to leverage the use of RhinoMocks to ensure the views are properly initialized:

          using (_mocks.Unordered()) { _view.Name
= "Jacob"; } _mocks.ReplayAll(); _controller.Action(); _mocks.Verify(_view);

All we've done here is created a mock from the view interface, rather than emitting the wrapper class. Again, another added benefit is if the view changes, compiling the tests will also break. The sooner things break after a change the better, and the build is pretty soon. Although, with ReSharper, it's nice to see red squiggles appear as that's even sooner.

I was trying to think of a way to introduce this post, and I realize that here at Eleutian, we hate strings. We don't hate all strings, it's mostly string literals that we hate. Not even all string literals. But most of them. A good portion of the work we do to make our code more solid involves removing string literals. Anybody familiar with MonoRail has seen lines similar to the following:

RenderView("Home", "Action");

          <
          a
          href
          ="${siteRoot}/Home/Action.rails"
          >...</a> ${UrlHelper.LinkTo("Home",
"Action")}

And so on, see all those string literals that refer to things that aren't really string literals? At first glance, we can get rid of the Controller string by doing something with typeof(HomeController).Name and chopping off the Controller suffix. That'd be an ugly static method call everywhere and still leaves "Action" to be dealt with. We want things to break if HomeController changes names and we want to know where HomeController is referenced.

One of our rules is to turn potential run-time errors into potential compile time errors if at all possible.

It's funny, but the compiler is our first test, and a good one at that. We found ourselves using those controller names, area names, and action names in a variety of situations - redirections, view rendering, generating url's in the views, etc... Anytime I see this I'm annoyed:

Redirect("AnotherAction.rails?parameter=34");

or even worse:

Dictionary query = new Dictionary(); query["parameter"]
= 34; Redirect("AnotherAction.rails", query);

You'll notice that our life would be much easier if methods were first-class objects. They aren't in C# 2.0... or even in 3.0 (without lambda functions) and so this is where we are.

Aaron and I talked things over, complaining on end about how frustrating things were. Our problem boiled down to turning the controller action's into something we could reference, so we decided to try a little code generation magic. We wanted to be able to write code like the following:

MyActions.Action().Render()

Site.AdministrativeArea.Home.Action(24, "Jacob").Redirect()

And so on. In order to do this we have a tool that runs as a pre-build step that does the following:

• Walks the source tree, parsing *.cs files, looking for controllers. We have to parse source, we can't use reflection because the same source files we're parsing will be using this generated code.
• Look for public methods (the actions) on the controller.
• Generates a class (HomeControllerNode) that has a method, with the same prototype as the action, that returns a ControllerActionReference:

          public
          partial
          class HomeControllerNode
{ private IControllerServices _services; public HomeControllerNode(IControllerServices
services) { this._services = services; } publicvirtual HomeControllerViewsNode
Views { get { returnnew HomeControllerViewsNode(this._services);
} } [System.Diagnostics.DebuggerNonUserCodeAttribute()] publicvirtual ControllerActionReference
SomeAction() { returnthis._services.ControllerReferenceFactory.CreateActionReference(this._services.Controller, typeof(HomeController), "Home", "Administrative", "SomeAction", new ActionArgument[0]);
} [System.Diagnostics.DebuggerNonUserCodeAttribute()] publicvirtual ControllerActionReference
AnotherAction(string name) { returnthis._services.ControllerReferenceFactory.CreateActionReference(this._services.Controller, typeof(HomeController), "Home", "Administrative", "AnotherAction", new ActionArgument[]
{ new ActionArgument("name", typeof(string),
name)}); } } }

• Generates a stub class for area's with properties for each controller in that area (they return HomeControllerNode instances) We introduce a default root area that all top level controllers and other areas are children of:

          public
          partial
          class AdministrativeAreaNode
{ private IControllerServices _services; private HomeControllerNode
_home; public AdministrativeAreaNode(IControllerServices
services) { this._services = services; this._home
= new HomeControllerNode(this._services);
} publicvirtual HomeControllerNode
Home { get { returnthis._home;
} } }

• Walks the Views subdirectory looking for *.brail files mapping them onto their controllers.
• Generates a class (HomeControllerViewsNode) with methods for each view that return a ControllerViewReference.

          public
          partial
          class HomeControllerViewsNode
{ private IControllerServices _services; public HomeControllerViewsNode(IControllerServices
services) { this._services = services; } [System.Diagnostics.DebuggerNonUserCodeAttribute()] publicvirtual ControllerViewReference
SomeAction { get { returnthis._services.ControllerReferenceFactory.CreateViewReference(this._services.Controller, typeof(HomeController), "Home", "Administrative", "SomeAction");
} } }

• Generates a partial class for the controller class itself with two properties - MyViews and MyActions that return the ControllerNode and ControllerViewsNode instances for that controller.

          public
          partial
          class HomeController
{ publicvirtual HomeControllerNode
MyActions { get { returnnew HomeControllerNode(this.ControllerServices);
} } publicvirtual HomeControllerViewsNode
MyViews { get { returnnew HomeControllerViewsNode(this.ControllerServices);
} } protectedoverridevoid PerformGeneratedInitialize()
{ base.PerformGeneratedInitialize(); this.PropertyBag["MyViews"]
= this.MyViews; this.PropertyBag["MyActions"]
= this.MyActions; } }

In the generated code, we pass a reference to an IControllerServices implementation down through the hierarchy, which provides the ControllerReferenceFactory that creates the ControllerActionReference and ControllerViewReference objects. Our EleutianController class has a property on it - Site, that returns the RootAreaNode so the top of the site can be reached from anywhere. This is also always placed into the controller's PropertyBag, along with MyActions and MyViews. The PerformGeneratedInitialize method, that's called in our base class so that each controller can add it's own MyViews and MyActions, which don't live in the base class.

Our ControllerActionReference class has Redirect and Transfer methods as well as a Url property. So now we can do the following:

          <
          a
          href
          ="${Site.HomeController.Action(200,
true).Url}"
          >...</a>

ControllerViewReference has a Render method that does the appropriate RenderView call on the controller. Now we've accomplished a lot of things:

1. No more string literals. If we rename something, the build fails. Our views will fail when they're opened and not when links are followed, it is pretty easy to test that a view compiles.
2. All URLs for redirections/transfers are always well formed and include necessary parameters with proper type checking.
3. Provided ourselves with Intellisense when building URLs in tests and controllers. (Sexy? Yes.)

Speaking of testing, in our controller tests we have a custom IControllerReferenceFactory that returns mock ControllerActionReference instances (via RhinoMocks) So now redirections, transfers and view renderings are just mocked method calls:

          using (_mocks.Unordered()) { _controller.MyViews.AnotherView.Render();
} _mocks.ReplayAll(); _controller.SomeActionThatRendersAnotherView(); _mocks.VerifyAll();

Which is much cleaner than string comparisons on _controller.SelectedViewName, especially if a redirect with parameters is expected in an action. This has simplified our life and given us incredible peace of mind, well worth the time to implement - which was relatively simple. Whew.

My team and I are whores when it comes to productivity tools. At the moment I have and use so many in concer it's kind of amusing. I've actually spent a decent amount of time working with the various tool authors to get their tools to play more friendly so that I can use them together. Here's a rundown of some of the tools I use every day:

• CodeRush with Refactor! Pro
• I'm pretty sure I couldn't happily write code without this, and I even disable or neglect half the features.
• I use and customize the templates heavily. They're so customizable its stupid. You can literrally do just about anything, and if you can't do it, you can write a plugin to help you do it and integrate it with any other template. I'll post the set of plugins I wrote for CodeRush later.
• The refactorings are great and rank high on the visual appeal, discoverability and usability scales.
• ViEmu (Visual Studio vi/vim emulation)
• I almost took it upon myself to write this. When I worked at Microsoft, I submitted requests to the Visual Studio team to write this. Jon came to the rescue and implemented the now near-perfect ViEmu and he will forever be my hero.
• Vim is really so much faster than regular text editing it makes transferring code from your mind to the screen much less of a barrier. If you haven't heard of it, used it, given it a good shot, or even if you haven't fallen in love with it, I'd strongly recommend doing all of those things. Here are some resources to get you started:
• Efficient Editing With vim
• The vi input model
• Graphical vi/vim Cheat Sheet and Tutorial
• One quick tip: use Ctrl+[ instead of escape to get out of insert mode, it'll save you at least 15 seconds a day!
• ReSharper
• This one's new to me. I've tried it twice in the past and it's only done bad things--crashed, played badly with CodeRush or ViEmu, etc. The latest version however, seems to play fine with everything I have installed, so it's going to stay. Yes, I use CodeRush AND Resharper. I told you I was a productivity tool whore.
• The biggest feature for me is the Error Highlighting and QuickFixes. Most of the refactorings CodeRush does (often better) but there are a few that are pretty slick.
• The navigation features are great too. Real fast and real usable, much better than scrolling through our 40 project solution.

Previously I mentioned that we switched to MonoRail for all of our new features. Well, MonoRail doesn't make page localization any easier than Web Forms does.  As a matter of fact, it actually breaks an important part of ASP.NET's localization (something I should probably submit a patch for, heh).  Basically, the DefaultResourceFactory in MonoRail creates IResources that wrap ResourceSets, which will not resolve resources to their parent resource. In other words, if you have Res.ko-KR.resx which defines String1 and Res.resx which defines String1 and String2, then calling GetString on a ResourceSet when your locale is ko-KR with String1 will work, but String2 will fail.  Calling GetString with any other locale, will return the String2 from Res.resx. To get around this, we created an IResourceFactory that returns IResources that wrap ResourceManagers instead of ResourceSets, which are capable of properly traversing the resource tree.  I'll probably submit this code soon. 

Anyways, in order to localize with MonoRail, you still need to create your resx file, add an attribute to your controller to map that resx file to something in your view's property bag, and create, name and initialize each string in your resx file.   

What we did was create a new generator like the one mentioned in my previous post that converts mybrail files to brail files.  All it does is convert this: 

${g.Test: Global Text} <br/> ${v.ViewTest:
View Text} <br/> ${c.ControllerTest:
Controller Text} <br/>

To this: 

${g.Test} <br/> ${c.Localization_ViewTest} <br/> ${c.ControllerTest} <br/> 

Now a few things happened here:

1. A file called Global.resx was created.
2. A file called Test.resx was created (Test is the name of the controller)
3. A resource called Test was added to Global.resx and initialized with the value "Global Text"
4. A resource called ControllerTest was added to the Test.resx and initialized with the value "Controller Text"
5. A resource called Localization_ViewTest (Localization is the name of the view) was added to Test.resx and initialized with the value "View Text"
6. v.ViewTest was converted to c.Localization_ViewTest

Essentially, what you end up with, is one resx for your global strings, and one resx per controller, with view specific strings being stored in the controller resx with ViewName_ prefixed to them.  There's still one piece missing to the puzzle, which is how do the views know what g and c are? Do we attribute each controller with a g resource and a c resource? No... that would be too much work for us. Instead what we do is define a new IControllerDescriptorProvider that wraps a DefaultControllerDescriptorProvider and adds appropriate ResourceDescriptors to the Resources collection of the descriptor built by the DefaultControllerDescriptorProvider.   

There is some room for improvement, like gracefully handling the case where you define and give a value for a resource twice in the same file or two seperate files, e.g. ${g.Test: Hi} ${g.Test: Hello}.  In this case, g.Test will be Hello.  In the case where they're in seperate files, it'll depend on which one was saved last (ew).  A decent way around this would be to detect this happening and pop a message box if you try to do this.

<asp:HyperLink runat="server" ID="_lnkForgot" NavigateUrl='~/ForgotPassword.aspx' Text='<%$ Resources: PageStrings, Login_lnkForgot_Text %>' />

<img src='<%= ResolveClientUrl("~/Images/img.gif") %>' />

1. Create a generator that extends Microsoft.CustomTool.BaseCodeGeneratorWithSite for .aspx files and do your preprocessing here.
   
2. Create a wizard that extends Microsoft.VisualStudio.TemplateWizard.IWizard to set up a file hiearchy like this:
   • Page.myaspx
     • Page.aspx
       • Page.aspx.cs
       • Page.aspx.designer.cs
3. Create an ItemTemplate for your item that contains these files and sets your custom tool to the generator you created in step one.
4. Add a new myaspx to your project and make sure you don't ever modify the aspx directly (this takes some getting used to)

• Add runat="server" tags to all <anything:anything> nodes that don't have it.
• Replace "~/blah" with an appropriate call to ResolveClientUrl
• Do some localization magic

<asp:HyperLink ID="_lnkForgot" NavigateUrl='~/ForgotPassword.aspx' Text="$:Forgot your Username or Password?" />

• Make databinding strongly typed.  This requires a bit of help, as you can't easily infer the type being bound by just inspecting the source.  Our solution was to add a DataType="Class" attribute to whatever the repeating control was.  For example:

  
  <asp:Repeater ID="repeater" DataType="BoundClass">
    <ItemTemplate>
      <asp:Label ID="textBox" Text='<%#@Name%>' />
    </ItemTemplate>
  </asp:Repeater>

Notice the @ in the <%#%> tag.  That gets replaced with ((BoundClass)Container.DataItem), so you can do things like <%# String.Format("{0} {1}", @FirstName, @LastName) %>

So that's how we made ASP.NET more manageable.  Now, there are still several issues with ASP.NET WebForms that caused us to eventually switch to MonoRail, which also benefits from preprocessing, but I'll post on that later.