The Unit Test Is The Specification

From TheSourceCodeIsTheSpecification: I take "specification" here to mean the requirements, what is wanted. If that's correct, the specification must be independent of the source code, or else every program is 100% correct and 100% what the customer wanted. This is false to fact.

For what it is worth, the answer the above question is no. Specification, as stated in TheSourceCodeIsTheSpecification is not the requirements. Lately, people call it the detailed-design. My view is the source code is the very detailed blue-prints, what most people think of as a specification. It does not replace good CrcCards, behavior models, pattern documentation, abstract interactions, or other high-level design artifacts that are above the implementation but below the SystemMetaphor. So, the term specification as it was used in TheSourceCodeIsTheSpecification is means the functional or low-level specification for the source-code. In my opinion, modern languages remove the need for this type of specification. This type of specification was required in the days where you could only type in code once and turn it into cards. You wanted to plan the code out before you wrote it. In today's world, the source-code has become the specification. -- RobertDiFalco

UnitTests codify the requirements, what is wanted, extremely well. A program may pass the UnitTests, in which case it is to specification. Or it may fail the UnitTests, in which case it is not to specification (bugs in the 'specification' notwithstanding).

You can easily convert a small part of a specification, such as an example, into an assertion in a UnitTest. Converting it to bug-free code is much, much harder.

Wouldn't a more general statement be (for XP at least) the TestsAreAnExecutableSpecification? UnitTests specify the units and AcceptanceTests specify the system. -- TomAyerst

You can easily convert a small part of a specification, such as an example, into an assertion in a UnitTest. Converting it to bug-free code is much, much harder.

Actually, I've found that writing the right test is hard, but once I've done it writing the code is (relatively) easier. --SteveFreeman

Perhaps I should say 'Converting it to bug-free code in the absence of a UnitTest ...'

Points to note:

Not all testing is UnitTesting.
The word 'specification' is ambiguous. 'Requirements' and 'design' are not nearly as.

-- MattRickard

This page will be much improved by dispelling the definite article the in a number of places. We can clearly see how a well written UnitTest (with answers provided) can specify the behavior of a section of code very nicely. The tests constitute a specification, not the specification, of which there could be many. The nice thing about specifying by writing tests is that it dispels a whole bunch of ambiguity for the same amount of money.

A specification is not the requirements, but there ought to be a pretty close parallel. An effective specification needs to reveal the system behavior that satisfies requirements, and need not reveal any more than that. In this sense, the code contains a specification for the system, but also contains a lot more. So, what code is essential specification and what code is not? As stated above, a test can serve nicely as a specification, provided the success criteria are provided as part of the test. But scope matters. A UnitTest specifies one module, not an entire system. Saying that "UnitTests constitute a specification of the system" errs on the same side as saying "code is a specification of the system", in that they (collectively) contain too much information to be an effective specification of the system.

By the way, when you say "UnitTest", just what exactly is included in that bundle? Is there really anything tangible in the notion of "test" that we can lean on to specify a system, or do we really depend on the specification of a test for that?

-- WaldenMathews

''I take "specification" here to mean the requirements, what is wanted. ... 100% what the customer wanted.

The specification can only describe what has been built or what is intended to be built. You are never going to get 100% of what the customers want or need; you will always be able to improve and do better.

Part of the problem with the term "specification" is that it has a wide range of meanings. It can be as little as a list of bullets in a magazine ad to an almost line by line PDL representation of the code.

UnitTests are on classes. Those classes have to exist to have a UnitTest. The classes are always changing. Requirements have to exist in discussions with the customers before the classes exist. Therefore, classes and UnitTests can't be requirements. Requirements must be in a form not tied to the code because they are universal in nature. Many implementations can satisfy the specification, yet the specifications remains the same. -- AnonymousDonor

UnitTests do not have to be restricted to the classic waterfall definitions. Most modern use of "UnitTest" actually represents what was previously known as "Integration Test." From TestFirstDesign, we see that an executable test should exist prior to the code. Furthermore, a requirement (note my deliberate use of the singular) is not fully defined until its method of verification is defined. Therefore, the definition of the requirement and test are synonymous. What is in question is what will be considered the System of Record for the agreed upon requirement and test; should it be a textual document or an executable set of tests?

Why do "Requirements have to exist in discussions with the customers before the classes exist"? Consider the implications if that is not true.

The only thing I know how write them on is actual real life code that compiles and runs. Maybe you mean some other kind of test other than a UnitTest. [Please read TestFirstDesign to see how to write UnitTests first.] -- AnonymousDonor

Please understand you need to have classes and code for TDD. -- AnonymousDonor Why?

I'm beginning to wonder WhatIsaSpecificationAnyway. -- MattRickard