Tag Archives: tdd

Making TDD even more efficient

Kent Beck is still kind of working on unit testing tools — a couple of simple but great ideas that are baked into his re-launched JUnitMax:

  1. When running a test suite after a failure, give the most useful feedback first — by running the failures first before the rest of the suite
  2. Otherwise, run the fastest tests first. This gives you 99% of the feedback as fast as possible
  3. Alas, only currently available for Eclipse.

How to create an NUnit test project that is also a self-running console app .exe

  1. Create your NUnit Test project as a Windows Console Application, not as a Class Library.
  2. Then make your main Program look like this:
    public class Program
        static void Main(string[] args)
                new[]{Assembly.GetExecutingAssembly().Location }
        [TestCase("Aa - Bb")]
        public void WhenValidatingForename_should_accept_valid_characters(string validInput)
            var result= new ClassUnderTest().Validate(validInput);
        public void WhenValidatingForename_should_reject_invalid_characters(string invalidInput)
            var result= new ClassUnderTest().Validate(invalidInput);
  3. Then, add a reference not only to nunit.framework.dll but also to nunit-console-runner.dll

You now have a self-running executable that runs all your tests, but still behaves in the usual way in a build script, or when running tests inside Visual Studio with TestRunner or Resharper or similar.
NB You may need to check if your build scripts are hard-coded to expect a Test project to be a .dll.

A javascript unit testing framework in 50 lines – plus some assertions

Surprised by a TDD session at XP-Man in which we rolled our own unit test framework from scratch – using the growing framework itself to test itself as it grew – I added some basic assertions to my 50 line javascript test runner.

I suggest that assertions should be thought of as separate to a test runner. Assertions are at the heart of – and should grow into – your domain specific testing language. So you should think of assretions as owned by your application, not the testing framework. As your application grows, so domain specific assertions should grow. A testing framework should probably provide minimal assertions for the language it runs on: the ‘primitive’ true/false/equal/notEqual assertions which will be used to define more domain specific assertions; and doing the legwork of tedious but common cases, such as testing equality by value of complex objects and collections.

In the case of javascript, the below might do. The tricky thing for assertions is to come up with something that is fluent and not verbose. C# extension methods are perfect for this. In javascript one could add methods to Object.prototype, but that doesn’t have the same scoping restriction as C# so feels too much like trampling all over everyone else’s garden: it’s poor namespacing and a failure of good manners.

/* Assertions for a test framework. http://www.cafe-encounter.net/p756/ */

function Assert(actual, assertionGender){
    this.Expected=  assertionGender ? "Expected" : "Did not expect";

function assert(actual){return new Assert(actual, true);}
function assertNot(actual){return new Assert(actual, false);}

Assert.prototype.IsTrue = function(msg){
    if( this.actual == this.notted ){ throw msg||this.Expected + " true.";}

Assert.prototype.Equals = function(expected,msg){
    if( (this.actual==expected) == this.notted ){
        throw msg|| this.Expected + " " + this.actual + " to equal " + expected ;

Assert.prototype.EqualsByPropertyValue = function(expected,msg){
    var actualValue =  JSON.stringify( this.actual );
    var expectedValue = JSON.stringify( expected );
    if( (actualValue == expectedValue) == this.notted ){
        throw msg|| this.Expected + " " + actualValue + " to equal " + expectedValue + " by value";

    new Specification("SpecificationsForPrimitiveAssertionPasses",{
        isTrueShouldBeTrueForTrue : function(){
        equalsShouldPassForEqualArguments : function(){
            assert( 1+1 ).Equals( 2 );
        equalsByPropertyValueShouldPassForValueEqualArguments : function(){
            assert( { a: "a", b : function(){ return "b";}} )
                .EqualsByPropertyValue( { a: "a", b : function(){ return "b";}} );
        assertNotShouldReverseTheOutcomeOfAnAssertion : function(){
            assertNot({ a: "a"}).EqualsByPropertyValue( { a: "b"});

    new Specification("SpecificationsForPrimitiveAssertion_Failures",{
        isTrueShouldNotBeTrueForFalse : function(){
        equalsShouldFailForNonEqualArguments : function(){
        equalsByPropertyValueShouldFailForDifferingPropertyValues : function(){
            assert( { a: "a" } ).EqualsByPropertyValue( { a: "A" } );
        equalsByPropertyValueShouldFailForDifferingProperties : function(){
            assert( { a: "a" } ).EqualsByPropertyValue( { aa: "a" } );
        assertNotShouldReverseTheOutcomeOfIsTrue : function(){
            assertNot({ a: "a"}).EqualsByPropertyValue( { a: "a"});
        assertNotShouldReverseTheOutcomeOfEquals : function(){
        assertNotShouldReverseTheOutcomeOfEqualsByValue : function(){
            assertNot({ a: "a"}).EqualsByPropertyValue( { a: "a"});
        assertTrueFailureWithCustomerMessageShouldOutputCustomMessage : function(){
            assert(false).IsTrue("This assertion failure should output this custom message");
        assertEqualsFailureWithCustomerMessageShouldOutputCustomMessage : function(){
            assert(1).Equals(2, "This assertion failure should output this custom message");
        assertEqualsByValueFailureWithCustomerMessageShouldOutputCustomMessage : function(){
            assert({a:"a"}).EqualsByPropertyValue( 1, "This assertion failure should output this custom message");