The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

The best way I've found to bring Mangement is demonstrate the ROI. If you have decent defect tracking, keep tabs on how much yours go down once you start using TDD. Try and work out all the time saved and present if with real business value.

You can write software with no bugs and which does what it should do but is still a heap of impossible to maintain and undocumented spaghetti. Assessing the quality of software requires more than a "well, it works so it must be good" evaluation.

Agreed; I find that, for complex functionality, TDD can sometimes encourage a "poke at it until it works" attitude, where you make almost random changes in implementation until you get the behavior you're testing for. Then, inevitably, an edge case you didn't originally test for comes up, and you're back to poking your code trying to make the new tests pass.

Of course, TDD doesn't have to be that way, as refactoring your code is an important part of the TDD process, but it can happen if you focus too much on the desired output and not enough on maintainable implementation.

I mostly agree with Chris' answers to the 14 questions, so let me just add a few comments to some of them.

Originally Posted by phpimpact

1. BDD is an evolution of TDD.

Originally Posted by Chris Corbyn

1. True (it's still a form of TDD though)

It's a form of TDD with different terminology and with tests chunked small enough to test a single behavior. Typically, that means more than one test method per method under test.

Originally Posted by phpimpact

2. In order to write code, first you have to write a test.

Originally Posted by Chris Corbyn

2. True for the most part. I don't write tests for simple accessors for example.

The principle is, test anything that could fail. Accessors usually don't, but if they do for whatever reason, they should be tested and the tests should be written first.

Originally Posted by phpimpact

3. In TDD you cannot write code before writing a test, that includes a use cases analysis.

Originally Posted by Chris Corbyn

3. Mostly true. I'm not sure what your definition of "use case analysis" is though. I often open a blank file in the very early stages and sketch out how I'd like to use the API before I ever write it. Nothing final, just to get a rough feeling for it. This is NOT the same as writing code. It's the equivalent of grabbing a pad of paper and scribbling a few ideas down. My definition of "writing code" for the purposes of this discussion is "implementing the API".

A use case is a requirements specification. It's not a sketch of the API. XP uses the simpler concept of user stories instead. Whether you use one or the other is not really relevant to the issue of TDD. Requirements specifications are not code. They resemble test code more than they resemble implementation code, so they can be replaced with acceptance tests if the user / customer is capable of reading and understanding them.

Originally Posted by phpimpact

4. The primary goal of a unit test is to design a system from the developer's perspective.

Originally Posted by Chris Corbyn

4. False. It's just as much about designing from a user's perspective. This is the whole emphasis - to focus your thoughts on the interface, not on the implementation. You're documenting behaviour upfront and only then are you implementing the code to provide that behaviour.

I'd say the developer mostly, since the user doesn't see the internal APIs that are tested with unit tests. Acceptance tests are another matter.

Originally Posted by phpimpact

7. Once you have written some code, you cannot use the TDD technique.

Originally Posted by Chris Corbyn

7. True, provided you're referring to only that specific component. You can have selected parts of a system developed under TDD and other parts developed without. Just because you didn't use TDD on component X does not mean you cannot use it when you come to develop component Y.

If you've written some code without tests, you can 1) add tests to it and then 2) continue to maintain it using TDD. There's probably some refactoring needed between 1) and 2).

Use Case Analysis: This step narrows down the class list into those classes that are capable of performing the behaviour needed to make the system function successfully. If no classes yet exist for a system, they must be created before this step can be completed.

A use case analysis forces you to sketch the API. So that's why I was confused at the beginning. But I guess that the more TDD experience a developer has, the less he's going to analyse the system's behaviour before testing.

A use case analysis forces you to sketch the API. So that's why I was confused at the beginning. But I guess that the more TDD experience a developer has, the less he's going to analyse the system's behaviour before testing.

User stories are a specific technique that is used XP (extreme progamming) instead of use cases or other forms of requirements documents. The main difference is that user stories are much simpler. It's not a part of "traditional" development.

I didn't read the Wikipedia article on use case analysis before, and I have to admit it confuses me. To me it seems to blur the distinction between user requirements and technical design. But I'm not a guru on use cases, so whether it's "correct" or not I can't say. Different experts may have slightly different terminology.

EDIT: You're right. This is the definition of use case analysis. I wasn't familiar with the term. (More here: http://www.ibm.com/developerworks/ra...rary/5383.html) It doesn't blur the distinction, it describes the process from one to the other. I realize now that you're asking how you might use TDD in this rather elaborate process. As described, what it lacks from my point of view is primarily a clear realization of the limitations of up-front design. There's no harm in designing classes to the degree of detail proposed here (unless you spend too much time on it), but you have to be prepared to throw most of it away once you start getting real implementation code, because the code speaks and you need to listen. When develop the code using TDD, you discover things you were unable to realize when working on the design. The code you're referring to in use case analysis can then be seen as a design sketch rather than implementation code, and TDD presumably doesn't apply to it.