Hacker News new | ask | show | jobs
by jmathes 3743 days ago
TDD is best when you're writing code that talks to other code. So APIs, database models, etc. Pure functions, and code that has dependencies you can inject and mock. You should never abandon TDD in situations like this.

It's true that it's harder to write TDD for code with side effects or that draws UI. It doesn't really make sense to use TDD for this.

You shouldn't conflate the two. Also, "always pass the majority of tests" is a trap. You should always pass all the tests.

Source: I've been managing and working in automated testing and continuous integration systems for 8 years, dating back to before the term was coined. I was the manager of the system, at IMVU, that coined the term "continuous integration". I've also worked on testing at Sauce Labs and Google.
1 comments
kyberias 3743 days ago
You state that "TDD is best" in certain scenarios but fail to provide explanation. Why do you think TDD is best in the situations you enumerated? In fact, how does "database model" talk to other code?

I'm pretty sure unit tests, automated tests and continuous integration existed 8 years ago in 2008. According to wikipedia, CI was named by Grady Booch in 1991.

link
extrapickles 3743 days ago
I think they were referring to back-end part of a application or complete applications that end up as a back-end piece (SQL, HTTP server, etc) of a more user facing application. This is generally where the amount of state easily manageable and well defined.

Front end testing is much harder as you have quite a bit of state you need to manage, and things like "Is this button visible to a user" are hard for a computer to answer as for a computer you need to render the entire page, then use machine vision to look for the button and verify the text is a readable size (not a cheap operation). In the front end, you can't get away with only rendering part of it, since anything could trigger a modal/overlay, or cause some z-order/clipping/scaling issue.

link
jmathes 3743 days ago
I think TDD is best in the situations I enumerated because writing tests for single behaviors of single functions is easy, fast, forces you to discover errors that cause your tests to trivially test, and forces you to discover bugs in your understanding of the problem.

Continuous "Deployment", I guess. The term may have existed before I realize, but it certainly wasn't in popular use before this:

http://timothyfitz.com/2009/02/10/continuous-deployment-at-i...

link