Hacker News Reader

Comment by petercooper | Hacker News Reader

The point is, code evolves. It’s never “done”, so don’t write tests that presume it will be static and your interfaces won’t change.

That's exactly why one does TDD, so that you can both be guided in your design (code that's hard to test is probably crappy code) and also have confidence when it comes to refactoring. This is particularly important in a dynamic language.

Good tests are not written with the requirement or presumption that the codebase will be tightly coupled or be difficult to change. Good tests are written entirely to support change and to give the developer confidence in the ability of that code to change easily.

I think we need more and more materials out there on good TDD and OOD because I'm finding that a lot of really smart people have just never seen or experienced it and have been turned off by the first few slimy rungs of the ladder (including me, once!)

View on HN

I agree with a lot of what you say.

However, it takes a lot more time to write code guided by tests than it does to just write code. And you may end up throwing away a lot of those tests and rewriting them when the code changes in response to customer feedback.

In my mind that's the main argument against TDD.

I'm happy to write tests after the v1.0 of an application is shipped and I have sign-off from my customer, because it is clear then that the time is not wasted - they have the working product as soon as possible, after all.

However, in my world it's inevitable that I'll be assigned to another task almost immediately after I ship a product. Those tests often don't get written.

I suppose I'm accumulating a lot of technical debt, but everything seems to work...

i feel the exact opposite-- if you have a good test, the code is nearly trivial to write. the key is to always bounce back and forth between tests and code, so that you're always just writing the minimum possible thing that passes, which (when looking at a test) is super simple.

"throwing away tests due to customer feedback" is a red herring-- if you weren't throwing away tests, you'd be throwing away code. additionally, the goal with all development is to only sit down and write code when it's extremely unlikely it's going to change. you should be sure that you're not going to drop this thing you're writing, because you've done the necessary user research to be sure the feature is needed and usable.

"I'm happy to write tests after the v1.0 of an application is shipped and I have sign-off from my customer". if you're shipping untested code, that's a huge problem. the last thing you want is to deal with scaled feedback from a 1.0 release alongside ironing out code quality and reliability with tests

> the goal with all development is to only sit down and write code when it's extremely unlikely it's going to change

If only this goal were achievable! Unfortunately it is a frequent requirement of my job to show early prototypes and create new iterations of those products based on the feedback I receive.

additionally, the goal with all development is to only sit down and write code when it's extremely unlikely it's going to change.

To a point. But as a general rule, I don't agree. The goal should be to write code that's both loosely coupled and highly cohesive enough that you can defer as many changes or decisions as possible to the latest point possible. While this might involve spending more time in planning, the process of developing will itself impact the overall design (in most, but not all, cases).

"tightly coupled" is the norm (I'd pick on Rubyists, but really it's the problem in any language I'm familiar with). It's hard to get over the hump.

So I agree. On the other hand, I think it's also very pragmattic to say "this isn't working for me, there's more important things to focus on".

I think manual testing is underrated, and even integration testing is probably not given it's due as one of the better ways to test a product in an automated fashion.

Unit tests in the TDD sense aren't (IMO) all that useful as tests. I'm a big fan of the tweak in calling it Test Driven Design personally.

"I think we need more and more materials out there on good TDD and OOD..."

Which materials do you recommend?

Reply on news.ycombinator.com