Fragmented integration tests – aka the questionable value zone

Fragmented integration tests – aka the questionable value zone

In TDD, different styles of tests can be applied to cover different levels in your code base. Two or three years ago, if you asked me what they were, I would probably have listed them as:

  • Highest granularity – unit tests, quick to run, drive low-level class design
  • Fragmented – integration tests, testing higher-level components and external dependencies (e.g. real SQL database, fake message bus)
  • Whole system at once – slow end-to-end tests, testing for story/feature acceptance at the UI or client API level

However, it has become increasingly clear that fragmented integration tests (somewhere in the middle between unit and full-blown end-to-end integration tests) don’t really provide the same value as their brothers.

They suffer all the disadvantages of both unit and end-to-end tests:

  • Like unit tests, they require setting up mocks/test doubles for collaborating modules
  • Like end-to-end tests, they have a high cost of maintaining external components like databases and integrated third party systems (setting them up, populating them with the right test data, reverting changes for next time etc)
  • Like unit tests, they are brittle and not friendly to refactoring
  • Like end-to-end tests, they are slow to run

… and, over the lifetime of the code base, the only real benefit they provide is slightly faster feedback of problems than end-to-end tests. Is it really worth keeping them?

Best practice DDD/TDD ASP.NET MVC example applications

Best practice DDD/TDD ASP.NET MVC example applications

It’s no secret that I’m a big fan of the ASP.NET MVC Framework. One of the reasons I like it is because it’s opinionated – instead of leaving developers free to fumble things as they choose, it recognises that most projects will be more-or-less exactly the same, and imposes some conventions to keep everyone on the same path.

This is the same philosophy used by many other application frameworks, and it saves everyone time and confusion by providing well-thought-out standards that everyone’s familiar with. However, because ASP.NET MVC is a general purpose web framework, its conventions can only cover so much — guidance for other frameworks and patterns is left to the community.

One very important area (that inspired this article) is around object-relational mappers (ORM). If I’m using the ASP.NET MVC framework:

  • How do I reference a repository from controller?
  • What’s the best way of applying a per-http-request unit of work pattern?
  • What should it look like if I’m using NHibernate? LINQ-to-SQL? etc.

Thankfully, there are a few example applications available that demonstrate solutions to these questions (and many more):

Kym NHibernate, Rhino-Commons, Castle Windsor, NUnit, Rhino Mocks, jQuery, Json.NET
S#arp Architecture NHibernate, Ninject, MvcContrib, NUnit, Rhino Mocks, Json.NET
CarTrackr Linq to SQL, Unity, MSTest, Moq, Visifire Silverlight charts, OpenID
MVC Storefront LINQ to SQL, StructureMap, MSTest, Moq, NLog, CardSpace, Windows Workflow, OpenID
Suteki Shop LINQ to SQL, Castle Windsor, NUnit, Moq, log4net, jQuery

It’s really good to see some different opinions in implementation and design, across a range of frameworks. MVC Storefront is of particular note – everything is explained over a series of 20-or-so podcasts that include interviews with well-known .NET developers like Jeff Atwood (Coding Horror/StackOverflow), and Ayende (NHibernate).

Generating documentation with Doxygen

Generating documentation with Doxygen

A few days ago, I had my first experience with Doxygen, an open-source documentation generator similar to Javadoc.

After a few hours of documenting my code to a satisfactory level, I had a very professional-looking set of HTML documentation. At work the next day, I used Doxygen to generate code for a Visual C# class library, which had been documented with XML comments.

Doxygen supports most C-derived programming languages including C, C++, Java and C#. It also allows you to define custom pages and sections; you are not limited to code documentation.

Documenting a method is very simple:

/// @brief Calculate the sum of two values.////// Adds the two values together and returns their sum.////// @param[in] aa The first value./// @param[in] bb The second value.////// @return The sum of both values.////// @note This method is deprecated!////// @see operator+()int add(int aa, int bb);

A full list of Doxygen commands is available.