Hacker News Reader

Comment by jrockway | Hacker News Reader

Honestly I saw testing as part of the problem from time to time, with the attitude "if it passes tests it can be merged". Testing is useful but not so powerful, unfortunately.

I get into this argument with my coworkers from time to time, and I have to say I disagree a million percent. Tests are the only way you can see if the software is going to work.

After you make a change, how do you make sure the software works? By trying it out? Congratulations! That's testing! Now you just need to invest some mental effort in teaching the computer how to do that test for you, and now you can automatically achieve the same level of safety that you had before.

I'm all for code reviews too, but code reviews do not scale the way that tests do.

View on HN

I'm not against tests, but passed tests is not enough to merge some code from a programmer you don't know very very well, you really need to review the code in a very careful way, and this possibly may take more time or the same time as writing it from scratch...

Yep. Everything you said makes loads of sense. Seems provably true. But I'd be honestly curious how many people have noticed a correlation between a large unit-test suite and the quality of the software they use? I haven't. Of the projects whose source I've been exposed to it feels like I've dealt with as many bug-riddled projects that had lots of tests as I have solid projects that lacked them.

I think projects get off course... teams can develop a culture of 'having unit tests' instead of a culture of 'writing high quality software'. The way the TDD/XP camp talk about software bums me out. As if the test they decided (key word) to write set the software on some Manifest Destiny vector to perfection.

Again, I agree with you. Unit tests are awesome, and the benefit as scale is huge.. but I took antirez's comments as a shot across a different bow.

> I think projects get off course... teams can develop a culture of 'having unit tests' instead of a culture of 'writing high quality software'. The way the TDD/XP camp talk about software bums me out. As if the test they decided (key word) to write set the software on some Manifest Destiny vector to perfection.

The tricky part is that anything can become a cargo cult rallying point. Mediocre programmers can drive anything into the ground. Even a seeming no-brainer like the Law of Demeter can be misapplied to create byzantine systems if someone knows how write code, but isn't very good at it. The situation is ten times worse with test code because it's meta—there's no objective measure of quality for test code. At least with application code it's obvious for any user whether it works or not, but with test code it's all about how much manual testing time was saved, or how much smoother refactorings went.

I've long been skeptical of the claim that TDD or whatever makes you write better code. The way I see it, TDD forces you to put in the time to learn how to write automated tests. Once you are good at it, tests help you move faster by covering regressions and documenting your intentions. In Ruby tests can give a nice sanity check that is built into strongly-typed compiled languages. I truly believe in TATFT, but at the end of the day tests are still meta, and you can't polish a turd.

Really well put, and I should start off by saying I really like TDD. A lot. (also.. for anyone like me who had to look it up.. TATFT = Test All The Fucking Time)

>Mediocre programmers can drive anything into the ground

Sure, totally. But the XP/TDD cult gives them easy to follow instructions for doing so. There's almost a lowest-common-denominator talent-smoothing mantra behind some of these cultures. I think plenty of projects, teams, and people don't end up finding their potential as developers because they're obsessed with a religion that favors obedience to a silly process over intelligent, clever, elegance.

Okay. At this point we're probably drifting steadily off topic :)

Whoops, just forgot to add that new option into the docs.

That's the kind of thing he's talking about, not just the code itself behaving according to strictly defined unit tests, but the project as a whole, and its health.

1) Does it work 2) Is it being updated 3) Are the docs good enough to get my job done as a user 4) Can I tweak it to my specific use case? Options? Source code patch?

Reply on news.ycombinator.com