Round 3:

Jacob and Ayende continue to discuss DI on their blogs.

It seems that Jacob thinks that DI brings a lot of development overhead with it, which i couldn’t disagree with more. That is, if you don’t go overboard with the DI usage. I use DI where it makes sense to me, not because it’s fashionable or because it’s what the cool developers tell me to use. I mostly use it in places where it takes away from the development overhead, in the form of easy testability and perhaps even more important: fast tests. Nobody likes to run slow tests so getting them as fast as you can, while still correctly covering the functionality that you want to test should be one of your goals if you’re doing TDD.

So where does that leave DI? Well, i mostly use it when i want to test code that is dependent on components that can either be slow, or have erratic/unpredictable behaviour. And sometimes i’ll use it just because it makes something a lot easier to test. I certainly don’t use DI for each and every dependency in my code. This approach certainly doesn’t bring a lot of development overhead with it since it’s rather easy to do. Initially while coding, it might cost you a few more minutes. But that’s really not a lot is it? The time i save while being able to run my entire test suite in a matter of seconds whenever i make a change or add a new feature more than makes up for those few minutes i lost initially.

This post shamelessly links to a few other posts, but this is a pretty good discussion about the benefits of dependency injection (DI) and definitely a good read.

Round 1:

It starts off with Jacob Proffitt’s post where he challenges the benefits of DI beyond those of testability. Ayende then posted a good reply to it. Nate Kohari also has an excellent post defending DI.

Round 2:

Jacob replies, followed again by another Ayende reply. Aaron from Eleutian then chips in with another thoughtful post.

You’re probably wondering: “why the hell is he just linking to these posts?”. Well, i just like DI and wish more developers knew about it. For those who don’t know too much about DI, read my intro to DI and then read all of the posts i linked to above. You should have a pretty good understanding of DI and its benefits then.

Stefan Venken is a colleague of mine, and he’ll spend the next three weeks in Chennai, India to work together with our Indian colleagues. He’s covering the experience on his blog which should provide some interesting reads

So i’m working on a code generator at work, and obviously i want to do it the TDD way. I wasn’t quite sure how i could make sure that it would be easy to test.

This is what i came up with:

    [TestClass]

    public abstract class GeneratorTests<T> where T : new()

    {

        private SourceStringBuilder _expectedSourceStringBuilder;

        private SourceStringBuilder _generationSourceStringBuilder;

        private T _generator;

        protected SourceStringBuilder GenerationSourceStringBuilder

        {

            get { return _generationSourceStringBuilder; }

        }

        protected SourceStringBuilder ExpectedSourceStringBuilder

        {

            get { return _expectedSourceStringBuilder; }

        }

        protected T Generator

        {

            get { return _generator; }

        }

        [TestInitialize]

        public void SetUp()

        {

            _generationSourceStringBuilder = new SourceStringBuilder(0);

            _expectedSourceStringBuilder = new SourceStringBuilder(0);

            _generator = new T();

        }

        protected void AssertThatGeneratedCodeContainsExpectedCode()

        {

            Assert.IsTrue(GenerationSourceStringBuilder.ToString()

                              .Contains(ExpectedSourceStringBuilder.ToString()));

        }

    }

This base class can be reused for each test class that tests a specific generator:

    [TestClass]

    public class StandardPropertyGeneratorTests : GeneratorTests<StandardPropertyGenerator>

    {

        [TestMethod]

        public void GenerateCodeFor_SimpleColumn_GeneratedCodeContainsCamelCasedPrivateFieldDeclaration()

        {

            ColumnInfo column = CreateColumn("Test", DataType.Int32);

            Generator.GenerateCodeFor(column, GenerationSourceStringBuilder);

            ExpectedSourceStringBuilder.AppendLine("private Int32 _test;");

            AssertThatGeneratedCodeContainsExpectedCode();

        }

        private ColumnInfo CreateColumn(string name, DataType dataType)

        {

            return CreateColumn(name, dataType, false);

        }

        private ColumnInfo CreateColumn(string name, DataType dataType, bool nullable)

        {

            ColumnInfo column = new ColumnInfo();

            column.LogicalName = name;

            column.DataType = dataType;

            column.Nullable = nullable;

            return column;

        }

    }

How clear is this to someone who has no or hardly no knowledge of what these generators and SourceStringBuilders do? I’d like to know so if you have an opinion, please comment below

You may have seen the term Behavior-Driven Development (BDD) showing up on more and more technical blogs these days… so what exactly is BDD? Scott Bellware explains:

Behavior-Driven Development (BDD) is User Stories, Test-Driven Development, and Domain-Driven Design rolled up into a practice that unifies the three constituent practices. Is doing so, BDD leaves nothing of its constituent practices behind. Said another way, BDD isn’t an abridged representation of TDD, DDD, and user stories - it’s a sum of three practices that are rather deep on their own.

Be sure to read the rest of the post, very interesting stuff

Was just browsing the NHibernate forum and read something i didn’t know yet… if you have read-only data, you can declare the class as immutable:

<class name="Foo" table="foo_table" mutable="false">

from the NHibernate documentation:

Immutable classes, mutable=”false”, may not be updated or deleted by the application. This allows NHibernate to make some minor performance optimizations.

Even if it’s only a minor optimization, it’s still a nice feature

As part of Martin Fowler’s Signature Series, a new book on Continuous Integration has been released written by Paul Duvall (with guest contributions from other authors as well). The book is called Continuous Integration: Improving Software Quality and Reducing Risk… should be pretty interesting. I already ordered my copy