Lots of talk on the new Live Writer. I'm just glad I can finally use the Ctrl+RightArrow key combination again the way I'm used to.

The real topic of the day is repositories. In my last post, I raved about ActiveRecord but in that little mini-project, I didn't actually use any repositories. I'll admit that I didn't actually do strict TDD on that project, nor did I even write tests for it. The reason being...actually, I don't need to explain myself to you people. I have my reasons, lame as they may be.

But that was important because I now understand what Jimmy Nilsson was talking about in his chapter on PI for repositories. I'm back in PD mode implementing tests against my repositories and it now occurs to me: I'm going to need two repositories. A fake one for the tests and a real one that hits the database and wraps my use of ActiveRecord/NHibernate. (Yes, Nilsson talks about this very explicitly. Hillbillies ain't what you might call "book learners".)

To explain the issue (and thus, to pad my post) here is a sample test:

    [ Test ]
    public void ShouldBeAbleToRetrieveJobFromRepository( )
    {
        int jobNumber = 42;
        MockRepository mockery = new MockRepository( );
        using ( mockery.Record( ) )
        {
            IJob fakeJob = mockery.DynamicMock<IJob>( );
            SetupResult.For( fakeJob.JobNumber ).Return( jobNumber );
            jobRepository.AddJob( fakeJob );
        }
        IJob job = jobRepository.GetJob( jobNumber );
        Assert.AreEqual( job.JobNumber, jobNumber );
    }

So I implement a basic (read: fake) JobRepository that adds a Job object to List<IJob> and in GetJob, I iterate through the list and find it. In the real repository, it'll use ActiveRecord to pull it from the database.

But now I have a couple of questions. First, what's the best way to wire in the fake repository for the tests and the real one for production? Is this where something like the Windsor container comes into play (he said without totally knowing what it does)? You reference one repository in your test web.config and another in the production app.config?

Secondly, and more importantly, do I even need this test? Why am I testing to see if I can pull objects from a fake repository? I don't even think an interaction-based test would work here since the underlying implementation will be different for each repository.

In the book, Nilsson adds a layer of abstraction so that the repository itself will be the same in both scenarios. That pushes things out of the repository but you still need a fake implementation of something, in this case the abstract layer. In that case, it makes sense to test the repositories since they are always "real" implementations. But then I'm not so sure about testing the abstraction layer.

So...ummm...help, I guess.

Kyle the Faked-Out