How I reliably enter the Zone: TDD
en.heavyelectrons.com
en.heavyelectrons.com
I think TDD hampers design, as it places a penalty on every time you want to reactor code while you are still implementing it and it keeps you vested on current code, which is against the "keep it simple, and easy to change" principle. In languages like java, it may force you to break encapsulation and good design, just to have your code tested. (how many times have you see this comment: "don't use this, just for testing purposes") in side of methods.
If you must do testing, a functional level testing is much better. Where you test only the higher level methods that have are acting on the functionality, but don't care about the lower level/helper methods.
Take the holistic approach, and don't sweat the details. If you do a good job on breaking the implementation in small/reasonable sized methods, then it is easy to spot errors when you are developing. Try the best to avoid methods with side effects (modifying shared resources), and keep the methods dumb: input in, input out, no side effects.. Just test the one method that is being called for that particular functionality, and if everything is working well, your overall test should come out as positive.
What I really hate is mandatory: "you must cover 90% of your code with unit tests" type of orders by CTO/VP engineering types.
No, TDD doesn't mean that. TDD is where you write the tests _first_. This bestows numerous advantages that post-facto tests don't:
1) You think about the API as required by the person using the interface that you are coding up.
2) - and this is the killer - you are forced to create repeatable test data and fixtures (e.g. in memory sql databases a la sqlite). As the functionality and number of services builds up, you create, whether you like it or not, a large suite of easily instantiated, complex mock services that allow you to build truly automated and repeatable high level tests.
3) And you can then safely refactor much more reliably and confidently when features and ideas have changed.
I agree that writing tests after the fact is a waste of time. TDD saves time (and hair!).
[1] That's one reason why functional programming raises productivity.
>"If you must do testing..."
Are you suggesting that tests are bad in general?
TDD by definition is build the test first, and then develop, which is implies, test everything.
Most of the code people write is not really test worthy.
That is errant. You can create high-level tests for new functionality, and then implement the myriad of implementation details to fulfill that test. Until all of our languages and libraries have 100% test coverage, you must decide to draw the line short somewhere.
Disclaimer: I am not a TDD aficionado, and we don't practice it at the dayjob.
Amen, brother.
The only experience I have with TDD is for my own projects, working solo. Nobody will truly understand it if they don't come to it of their own choice.
http://www.amazon.com/Test-Driven-Development-Addison-Wesley...
But I just don't get it. I think you should unit test as you code, sure (for big things), but testing as a design strategy? As a way of "getting into the zone"?
I'm glad this guy seems excited about it. I'm trying to collect examples of people who actually use it out of their own choice. I think this is number 4 from the last six months.
Nobody wants to be behind the curve -- maybe TDD is the next evolution in programming styles. Or maybe it's just a reaction against heavy-handed, overdone design by architects. Or maybe a little of each.
The jury is still out with me.
But on a 1 or 2 person team? That looks like a completely different animal.
What we're finding, however (as consultants), is that companies are getting sold on lightweight technologies that work great at the small team level and then don't work so hot with fifty thousand developers. It's complex.
Thanks for the feedback. HappyTDDCoderCount++
I'm in a learning mode, however. I'm trying to gather all of the data possible. And by data, I mean real, live, large teams who not only use TDD but do so gladly and would never go back to the old ways. Not consultants, authors, teachers, methodologists, coaches, or anybody else who isn't developing code. We've got enough of that already in the biz.
In my small world I haven't come across those teams yet. I think several examples along those lines would do the most to show me that TDD was worth picking up both as a personal and as a coaching practice.
Having said that, in some ways we may be parsing words. I design in a lightweight fashion top-down and then code and refactor bottom-up, unit testing as I go. In some ways, this IS TDD, except that I'm not using the test-first mantra as a design crutch. I already know how to design.
A large team would probably imply a large codebase, so are you aware of attempts to separate those two variables? For example it's interesting to me that attempts to do TDD on large codebases have met with success.
Your response also raised another interesting question. TDD could be hard to scale with team size because of intrinsic issues or just the difficulty in 'infecting' a large group with it. I wonder which is larger part of the reason.