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.
-
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.LottApr 8, 2011 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?– user9483Apr 8, 2011 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.LottApr 8, 2011 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.– user9483Apr 8, 2011 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.LottApr 8, 2011 at 21:37
Add a comment
|
3 Answers
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.
-
+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.– stijnApr 9, 2011 at 7:31
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.
-
1This 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.– user9483Apr 9, 2011 at 5:00
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.
