Hacker News Reader

Comment by varispeed | Hacker News Reader

One of the problems I faced is that the university didn't teach TDD, I couldn't find any books about TDD and every single programming course didn't even have a section about TDD. It's like this was some kind of secret knowledge that only few had. I was only able to learn TDD when I joined one corporation and it was like a new world to me. I tried to learn as much as I could and then carry that to next jobs. It's better now, but I feel like this knowledge is somehow still not shared as much. People still, when they create a course, they commit little time to testability and explaining how you can validate what they say. I find it frustrating then when new people come to work, they severely lack testing skills and that is not a fault of their own, just there is very little real world examples and tutorials. Some open source projects have good tests coverage so that's a great way to learn.

View on HN

On the flip side, as a dev with 10 years exp, I think TDD is a process crutch designed to cover up poor engineering by adding additional time spent to all work.

Also the automated security scans. All new frameworks cover the cases. Real box ticking exercise.

Though I am a TDD fan I understand your point.

> Also the automated security scans

Yes and no. At $WORK we started using a security scanner and I'm triaging the issues. It's definitely a box ticking thing. OTOH I'm finding real, concerning issues.

There are people going for 100% coverage and pedantic unit testing so that it only works with that particular implementation they wrote and then when you want to change something, you'll have a pile of tests to change that don't add any value. Something like this we try to get rid of.

Kind of like animations. Mobile apps hide latency by adding transition animations that are longer than the load time.

The TDD advocates I have been exposed to are mostly cargo culting consultants and this alone makes me very sceptical. It has some good core ideas but I find that in practice it leads to unit tests that are highly coupled to implementation details. Quick to execute but almost worthless from a test perspective. Its best to throw them out after the inital implementation is done since the usually just become a burden to maintain. Black box at system boundaries are the only tests that bring value long term in my experience. I would really like to hear more details about projects that use TDD and how they use it a few years down the line. All I can find are toy examples..

It really depends on what you're building though.

Project I work at right now could really benefit from basic TDD principles, mainly just setting test / outcome matrices and basing production off of that (which logically follows into TDD). The requirements are largely set up front, yet we still shoehorn unit tests in after production is done, wasting both development and test time. Requirements rarely change in major ways, and they are often established months up front.

Other times I work on stuff where fundamentals change rapidly. At that point I'm spending 1.5x-2.5x the time just to include test I'm likely to remove, and TDD largely inflates time required I don't have or wish to spend. Often testing trivial things, too.

I guess it depends on what time period you’re talking about. There’s a million books on TDD and there have been for decades now. They’re commonly recommended on HN and easily found via google.

Reply on news.ycombinator.com