Is specification replaced by tests in TDD?

Question

I believe not, but as I read and read about testing in agile approach, separation between developers and QA, and between tests and specification becomes more and more fuzzy.

I read Test-Driven Development (TDD) as writing the tests before development so they guide developers how to implement particular feature or functionality/behaviour. This is the main difference I see with respect to traditional approach, where developers write tests after implementation or QA writes tests independently to verify implementation.

1. Doesn't TDD creates a danger that tests will replace specification in programmer's opinion?

In extreme case, I imagine a programmer writing the code that will pass only given test cases without understanding whole model. Like a student preparing for the exam, knowing the questions from the previous exam session without deep understanding of answers.

2. Who writes those tests that guide developers: QA or developers themselves?

If QA writes low-level tests, than she automatically constrains developer how to design APIs of basic classes and acts as a developer. On the other side, developers tend to forget about many test cases and write very basic ones. So I believe both players need to play in the game, but how and when they enter into the game? What roles they play in writing the tests in which phase of project?

Answer 1

Ideally not! I have suffered under the same lack of understanding the concept when I first wrote code. Think of unit tests in TDD more as documentation of the written code. BDD design may be closer to what you refer to.

Let me try and example: I have a requirement to take a data stream and transform this. In a specific way. The documentation can be an explanation that certain inputs will generate certain outputs.

I may use a unit framework to create tests that provide specific inputs and outputs but I want this to be as vague as possible as I will leave the actual design and implementation to the developer. This is really only a behavioural test. (see BDD on Wikipedia).

Assuming it is not a really simple transformation, the developer will likely decide to write a parser for the stream, a set of business rules (each of which ideally only deals with one requirement), maybe an object/domain model to represent the data and behaviour, all of these actions need to be tested one by one. So if the developer needs a method that should counts items of a specific type, then this method will need a test. A method that maps categories from one input to different categories of the output then this needs testing specifically.

In essence the purpose of these two types of tests is different. Behavioural tests/or UAT tests are to ensure the software does what it needs to do for completion of the project. Unit tests, are there to point a developer that make potentially code breaking changes to a very small unit of code so they can very quickly identify why and how they have broken this code.

Answer 2

Point of specifications should be communicating needs of the user. There can be different implementations which all fullfill the same specs. On the other hand tests in TDD should help programmer to ensure that implementation works correctly.

It is true that best specifications are testable and if you can automate testing of them, it helps ensuring that right product is built and deciding when it is ready. This is called Acceptance Test Driven Development (ATDD) or Behavior Driven Development (BDD). One nice explanation how to do this is described in book Specification by Example by Gojko Adzic.

However, there is need for tests also on other levels. Unit tests should be written by programmers to make sure the lowest level components they are building are working correctly. Intergration tests could be written by programmers or testers as well as system level tests and whatever else is needed.

In short, test driven development does not endanger the scope. It is still there or it didn't exists previously either.

Answer 3

As Edu pointed out you're mixing up acceptance testing and test driven development.

Acceptance tests is to confirm you built what the customer wants.

Test driven development is not only to confirm you built what you think the customer wants but first and foremost to help you design a good solution based on your current understanding of what makes good code. This is why you should not skip the refactoring step in TDD before you have reached that goal.