Program Specification Through the Mechanism of Automated Tests

Please note, this post has moved to


4 Responses to Program Specification Through the Mechanism of Automated Tests

  1. I agree it’s ideal to have a program’s specification living with the codebase as executable tests, to avoid as you say the “great discipline and effort (that) is required in order to keep the specification and code in synch over time”.
    But I don’t think it’s ideal to have these specified in the programming language you use to write unit tests such as C# or MS Test.
    The reason is that it is very hard for the customer (most often non-technical) to collaborate on these with you if they’re written in C#.
    That’s why business readable DSLs for specifications such as Gherkin are becoming increasingly popular and successful, as they make it easy to specify from a customer/business centric point of view, which can be automatically translated into automated tests.

    • Adam Craven says:

      Hi Alister,

      Thank-you for your comment.

      In the post I said: “The test names look neat in the Test View in Visual Studio (when the Full Classname column is visible), and are readable just like their corresponding stories.”

      I stand by that statement.

      A non-technical person should be able to read this type of full test name and completely understand the specification.

      For example, there might be a class named Calculator with a specification that adding 2 and 2 results in 4.
      The test/spec would appear in the Test View as:


      This is not very technical. Ok, there may not be spaces between the words, but a simple tool could take this and make it prettier for a customer to read.


  2. Adam Craven says:

    Hi Alister,

    Please allow me to take back my previous comment!

    Funnily enough, some of the work that I have been doing over the last couple of months has been working on ways to increase the communication of business system functionality (via behaviour specifications) between development teams and customers – and thus establish a line-of-trust of tested functionality which is essential for a nicely shaped test pyramid…

    I guess back then I wasn’t ready to understand and see the larger business value of what you were saying!

    Best regards,


%d bloggers like this: