On Programming Deadlines • Hacker News Board

Re: On Programming Deadlines

#21

Post by stonemetal » Tue, Nov 01, 2011, 3:07 PM UTC

raganwald wrote: post #16

I think the article is fine as written, but in the interests of expanding on its ideas, I submit that writing tests first is a design technique and maintaining substantial test coverage is a regression-proofing technique. Both also serve as documentation. I mention this, because these three objectives--design, regression-proofing, and documentation--can be achieved in various other ways besides writing tests first, a…

I always hear that TDD is good for documentation, but most of my unit tests cover odd corner cases, weird error conditions and the like. It certainly isn't a show of what to do. What do you do with your unit tests that make them high quality documentation?

Re: On Programming Deadlines

#22

Post by stonemetal » Tue, Nov 01, 2011, 3:16 PM UTC

arctangent wrote: post #6

I don't have time to implement TDD.

How long do you spend manually testing? I find that developing automated testing(note I don't really care about TDD just unit testing and automated testing.) takes a little longer to get setup and running. Subsequent testing is cheaper because regression testing is free, and test code can be reused when developing new tests.

Re: On Programming Deadlines

#23

Post by mononcqc » Tue, Nov 01, 2011, 3:22 PM UTC

stonemetal wrote: post #21

raganwald wrote: post #16

I think the article is fine as written, but in the interests of expanding on its ideas, I submit that writing tests first is a design technique and maintaining substantial test coverage is a regression-proofing technique. Both also serve as documentation. I mention this, because these three objectives--design, regression-proofing, and documentation--can be achieved in various other ways besides writing tests first, a…

I always hear that TDD is good for documentation, but most of my unit tests cover odd corner cases, weird error conditions and the like. It certainly isn't a show of what to do. What do you do with your unit tests that make them high quality documentation?

That's often true of tests that were only used to check the validity of code, not its design.

In many uses of TDD, you will use somewhat broader specifications to test things. "The login system accepts any user with a valid name by returning '1' and returns '0' if the password isn't the right one". You can have a test to verify that without using special corner cases, and a test such as this one will likely look like any other normal use of your library or function.

If you develop all your requirements using TDD, then both the corner cases and the standard cases should be sitting in the test suite. The standard cases can act as documentation and a design tool while corner cases are really more there to insure things work absolutely right.

Re: On Programming Deadlines

#24

Post by arctangent » Tue, Nov 01, 2011, 5:17 PM UTC

wazoox wrote: post #19

arctangent wrote: post #6

I don't have time to implement TDD.

TDD is particularly valuable (I'd even say unavoidable) when writing modules, libraries and so on. It's extremely helpful on some tough program parts that aren't enough defined in behaviour by the spec. Writing tests first in these case will avoid you countless traps, particularly in "the other 90%" as mentioned in the Cargill's law: "The first 90 percent of the code accounts for the first 90 percent of the developme…

I can see how TDD could be useful for writing a relatively static piece of code, especially code that is likely to be reused by a lot of people.

But I develop web applications in 1-week sprints for my stakeholders and they're likely to change their mind about what they want at short notice.

In these circumstances it simply doesn't make sense to write tests up front. I don't even have time to write a lot of tests when I'm done :-(