Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite

I've heard of TDD as an organizational development paradigm, where all developers are asked to let testing drive development, and I've also heard of organizations who don't embrace TDD so long as unit test coverage reaches close to 90 percent for the application. One thing I never hear is why an organization would set a standard for TDD specifically when it is an individual development discipline.

share|improve this question
Isn't an "organization" just a bunch of individuals? If each individual does better, doesn't the organization do better? I don't think I understand the question. Can you clarify how an organization is different from the individuals. – S.Lott Apr 8 '11 at 20:49
Who is to say that every individual using TDD is going to do better? Isn't that a broad generalization about how programmer's work best? – Brian Reindel Apr 8 '11 at 20:56
"why an organization would set a standard for TDD specifically when it is an individual development discipline" Confuses me. Isn't an organization just a group of individuals? If individuals embrace TDD -- and it benefits them -- doesn't it benefit the organization by definition? I can't see a distinction between "individual value" and "organizational value". Please help me understand the question. – S.Lott Apr 8 '11 at 21:16
@S.Lott: I think it comes down to how I would classify TDD over just writing unit tests. Even though a developer can certainly write a bad unit test, for the most part the practice helps support all developers (the organization). However, TDD involves a "fail first" paradigm shift in thinking and individual development coding practices. You're still writing unit tests (which benefits everyone), but now you have to do it the TDD way, which may not be as efficient for every individual. – Brian Reindel Apr 8 '11 at 21:34
"I think it comes down to..." I can't see a distinction between personal value and organization value in this comment. If a programmer works better with TDD, doesn't that help the organization overall? I don't the distinction between personal improvement and organizational improvement from your comment. – S.Lott Apr 8 '11 at 21:37

3 Answers

up vote 5 down vote accepted

The main benefit of using TDD instead of building your tests afterward is that the system tends to be more "clean", and by that I mean less coupling, responsibilities where they belong and a clear public API. Testing after the facts tend to produce tests designed to pass, jumping to the hoops that the system imposed (like having to connect to the database because the DAO is coupled with the database code).

All in all, I tend to mix approaches: Most of the time I TDD, some times I just code (specially when I'm experimenting) and use tests afterward to clean my mess.

share|improve this answer
+1 for mentioning expermenting. Testing is all nice and such, but if I'm writing code to talk to some obscure hardware device the very latest thing I want to do is slow myself down by first writing tests. Especially since at that point I can't even tell what the classes are going to look like, since I cannot tell how the device will behave. Instead, just dive in, have fun and get the thing working properly and cleanly asap. – stijn Apr 9 '11 at 7:31
up vote 3 down vote

Here's what I think you are getting at. Take a team/organization that is well entrenched in TDD. They hire a new programmer who is very good, but no experience with TDD and in fact, isn't convinced it really works (They hired this person to provide diversity and potential new ways of thinking.).

As long as the new person writes good code that meets the specifications and happens to fit in with the entire project without testing first, who cares? It's not the process but the product. I think it does matter. You don't code on an island. Eventually someone else is going to have to work with this code.

It doesn't matter if it is following formating standards, naming conventions, TDD, Scrum, OOP or EIEIO all members should work within the framework of the team. It doesn't make them a bad programmer; just a bad fit. Not all teams are perfect nor are all methodologies, but unless you can change everyone else, you need to get on board at least for the current project.

share|improve this answer
1  
This is a good response, but I have to disagree, but only when it comes to TDD. For agile (Scrum) or OOP, where the affects can be felt by other developers, it is necessary to get on board. However, I honestly feel as if TDD is an area where testing/fail first is a "personal belief" in a programming practice and should not be enforced for the entire team. – Brian Reindel Apr 9 '11 at 5:00
up vote 0 down vote

One really good thing about TDD is that it forces you to think about the requirement first. Unclear spec can be hashed out before implementation. In organization level, it reduces the waste of resource, which is what every organization tries to achieve.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.