4 ms·
There is another way better way. Program to interfaces. Or write out all the methods you need, have empty bodies, and implement them one by one. From the lo
by ardit33 18y ago
There is another way better way. Program to interfaces. Or write out all the methods you need, have empty bodies, and implement them one by one. From the lower level/helpers, to the higher level ones. If any method becomes too large, or if there is a lot of redundancy, break it in smaller units.
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.
- ratsbane 18y agoThat is consistent with what I've been thinking, too. Also, I have the impression that TDD is more relevant to non-web development. Most of my work at the moment is in mod_perl and the i/o is all though web pages. How does TDD work with web development? Can anyone recommend any reading, video, etc?
- jcapote 18y agoGreat post, I was feeling lonely in the small-clean-code-works-just-fine-without-tests camp
- kristiandupont 18y agoWhile I can't prove it, my intuition tells me that when I do TDD, my designs are much more flexible and my code is much more reliable. Stuff that I would have buried in one class is often split into smaller classes. This gives some overhead, yes, but the tests are well worth the effort. >"If you must do testing..." Are you suggesting that tests are bad in general?
- ardit33 18y agono. Testing has it's place, in important functionality, high level features, or if you are dealing with 3rd party, outsourcing companies, and integrating their code (make sure their stuff works as specified). 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.
- aaronblohowiak 18y ago"TDD by definition is build the test first, and then develop, which is implies, test everything." 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.
- abdulhaq 18y ago> "you must cover 90% of your code with unit tests" 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!).
- gaius 18y agoTDD is a brute-force method for evading the need to understand side-effects. I consider situations in which TDD applies to be warning signs, not opportunities.
- deleted 18y ago[deleted]
- eru 18y agoSide-effects are evil [1] and it's good that TDD encourages you to minimize side-effects. [1] That's one reason why functional programming raises productivity.
- bryanl 18y agoYou can TDD at the functional level. I don't see what the big deal is.
- akkartik 18y ago"What I really hate is mandatory: "you must cover 90% of your code with unit tests" type of orders by CTO/VP engineering types." 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.