BDD vs. TDD - No contest!

BDD (behavior driven development) is the practice of writing an executable testable specification that describes the application’s behavior. This specification is often written in a fluent interface, or in plain English
Testing features of the application and verifying the user requirements have been met.

While in TDD (Test Driven Development) the focus is on writing tests that single out units of the application. Using mocking or not there are basically three kinds of unit tests, happy, unhappy and edge case tests.

Integration tests are also of good,  making sure that the application runs end to end. e.g. the C# DAL(Data Access Layer) accessing the database and returning expected and unexpected results with the code dealing with both scenarios.

Red,Green, Re-factor, here you write the unit test prior to writing the code, it fails. Then you write the code to pass the test, the test passes. Does it need re-factoring? Now's the time  to do it. Does it meet the requirements? If not start over again and this time think more about what is required. It takes time, 6 months on average, to become a good TDD developer no matter what language you use.

Top 5 TDD Mistakes

1. Not using a Mocking Framework
2. Too Much Test Setup
3. Asserting Too Many Elements
4. Writing Tests Retrospectively
5. Testing Too Much Code

My pet hate is when someone says we are doing Agile and not doing TDD, then your not doing Agile!

For years now I have struggled to make people see the benefit of TDD, even when I interview people who say they have TDD, they don't. What they confess to is number 4 writing tests retrospectively. I must be from another planet!

I hate SourceTree

One more point: can't say I like SourceTree. Still looking for a Mercurial GUI worth using. My biggest issue is that I'm a big user of annotate/blame (I have a very bad memory so finding out where/how/why a given piece of code was created or evolved is something I do at least weekly if not daily) and all the hg guis have absolute shit annotate. They also tend to look rather bad.

GitX is pretty good (I think I still prefer the original one over the Laullon gitx, but the Laullon gitx has an acceptable annotate view and look nice), and surprisingly the best annotate view I've seen so far is in bazaar's qt-based UI. The tools are not necessarily great overall (and the OSX interactions are downright weird), but the annotate is excellent.

Project Description

The LOOM.NET project aims to investigate and promote the usage of AOP in the context of the Microsoft .NET framework.


The concept of aspect-oriented programming (AOP) offers an interesting alternative for the specification of non-functional component properties (such as fault-tolerance properties or timing behaviour), as well as other crosscutting concerns. These are implemented as so-called aspects and at some point "weaved" to the other functional parts of the software.


The LOOM.NET approach is an approach that offers both: a static and a dynamic aspect weaver. The project was started in 2001 with the advent of Microsoft.Net and subsequently we released the first available aspect weaver for .NET. Like no other AOP-frameworks LOOM.NET significantly influences the Microsoft.NET AOP community.

How it works

Realized as a class library, LOOM.NET allows the language-independend definition of aspect code in the form of standard .NET classes. Both aspect weavers are fully binary compatible. Aspects written for Rapier-LOOM.NET would work with Gripper-LOOM.NET and vice versa.




An aspect class is a special .NET class with methods constructors and fields as well. At defined join points an aspect class becomes interwoven with a target class. Interweaving, strictly speaking, means that an aspect method will be interwoven with a target class method. The aspect method itself contains the aspect code and is defined within the aspect class. It has a special aspect method attribute applied. This aspect method attribute declares a method in the aspect class as an aspect method. Not necessarily every method in an aspect class is an aspect method and has this attribute applied. Methods without this attribute will not be considered for the weaving process.


A target class is a regular .NET class. The one and only restriction is that target class methods (which should become interwoven) either have to be virtual or to be defined via an interface. The weaving process will be initiated during runtime with a factory. Instead of using the new operator one uses the weavers factory method to produce interwoven objects.