Live data from Hacker News

Test-Driven Development is Stupid

geometrian.com

101–110 of 154 posts

Re: Test-Driven Development is Stupid

#101
post #6

> I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development And he's lost me in his first sentence. Unit testing, good unit testing at least, is not just about developing as it is about preventing regressions. A unit test that runs on every build ensure that something is true and that it stays true forever.

I'd be a lot less gung-ho about unit tests if all the tests I wrote always passed the first time I expected them to pass, and always stayed passing regardless of what changes people make to the code (including people who are not me). As neither of these things happens, I'm pretty gung-ho.

Re: Test-Driven Development is Stupid

#102

Earlier quoted context omitted.

What you described having tests , not doing TDD . That is, it's important to have those test cases verifying that your APIs still work, but that doesn't mean you have to design the APIs by writing tests, as opposed to designing by thinking about what you actually want to achieve.

Fair point. I was more referring to his comment here: I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development--a better strategy is to focus on competence and good design.

I disagree about that with the author too. I think testing and TDD should be clearly separated as two different things.

Re: Test-Driven Development is Stupid

#103
Well it is not a great rant but ultimately if you just read the conclusion he does have some good points. There really is no substitute for competence, the process can and does hinder good design, it is used as a false crutch against incompetence. And I do think that test first and in general a large overburden of existing tests does subconsciously limit refactoring and better design.

Thats not to say all testing is bad. I do some unit test and some functional/integration tests but by no means do I strive for some arbitrary % of coverage as if that means anything. You can have 100% coverage with completely brainless useless tests that are testing lots of simple low risk code. Any sense of security from that is beside the point if your team is incompetent, the overall design calcifies and becomes a mess and nobody fully understands how it all works.

Targeted testing I guess is how I think of it, very targeted. I work on a small project in a small team, in a much larger project with lots of devs I would have to rethink maybe but then again with properly sized teams (two pizzas) that don’t even come into existence.

Re: Test-Driven Development is Stupid

#104

Way stronger than I'd write, and I don't agree with it entirely, but the author has a point. Personally, what annoys me the most about TDD I've seen in the wild are two things: designing for tests instead of actual problems, and tests affecting the structure of "real" code. Designing for tests - the standard TDD approach, first we write tests, then we write code to pass the tests. Quite often the consideration of the…

> Tests affecting the structure […] is […] a strong code smell On the other hand, code being hard or impossible to test is often thought of as a code smell as well. Code that is easy to test is easier to understand — not in the least because there are tests demonstrating its use. Techniques such as dependency injection help a lot here.

Techniques like dependency injection can be really useful -- see Angular -- but too often I see a perfectly understandable piece of code expand into a mess of multiple constructors (only one ever called in production) and helper methods all so that strict unit testing can be done. The post's commit story was unsurprising. If TDD is being done this mangling often just happens upfront. DI is great in the same way interfaces are great, but if your code actually just cares about a particular implemention you instantiate wherever, or even better is built-in to the language, it's easiest to reason with that implementation. Taken to the extreme, you get Enterprise FizzBuzz.

Re: Test-Driven Development is Stupid

#105

Earlier quoted context omitted.

>You are writing code to test something that doesn't even exist yet. To piggyback on this... sure, the code doesn't exist yet, but the project specs do. And unit tests can help by making the required specification explicit.

In any other field, specifying a function by its value at a handful of points would be a bad joke. If you don't know what you want your code to do then tests will just make it harder to experiment, and if you do know then there's no harm in writing them after the fact.

When theseatoms says the specs already exist and the tests help, then you talk as if the test was the spec, it sounds like you're replying before you read.

Re: Test-Driven Development is Stupid

#107
Honestly this doesn't belong on the front of HN. There is no discussion value, or sense of professionalism. It's just a rant riddled with misplaced anger.

There are valid reasons to be against TDD, but it is not stupid. To call a methodology "stupid" is needlessly judgmental and really has NO place in the pragmatism and trade offs that so often go along with writing software. Anyone that calls a software methodology "stupid" so casually has no business writing software at all, nor blog posts about software.

I don't care how smart you are, or how right you are. If you want people to listen to you and consider your ideas, don't write posts like this, in this tone, at this length, with so little actual substance.

Re: Test-Driven Development is Stupid

#108
In my oppinion maybe it's too harsh to dismiss TDD. It's certainly good in some cases. But if you start using it everywhere everything will look like a nail when all you have is hammer. Clearly not everything is easily unit testable.

What I like about unit testing that it's forcing you to separate irrelevant code and prevents you from writing spagetti code.

In my personal oppinion you should test core functions as someone already said, which validates 90% code with 10% of time. And leave parts which can fail gracefully in case of a bug. It's not practical/impossible to test 100% of use cases of a big codebase. But you can test critical parts.

Re: Test-Driven Development is Stupid

#109
post #62

Earlier quoted context omitted.

>If you're doing TDD (or software development) like this, you're doing it wrong. What do you think is the right way to do it, then?

My point is: If TDD leads you to bad design you're doing it wrong. You are probably not listening to your tests and you are probably not taking care to refactor towards a better design. Maybe you are even writing bad unit tests [1]. BTW, if any technique in software development leads you to bad design, and you don't stop and try to improve something, you're doing software development wrong. If a technique does not he…

But that's a general counterargument for criticism against anything - "if it doesn't work for you, you're doing it wrong"!

Ultimately, we're too young a field to be able to replace common sense with a process.

Re: Test-Driven Development is Stupid

#110
This is a bad article, based on a fundamental misunderstanding of TDD, as virtually all the comments on the blog post itself and here on HN attest.

People don't spend weeks writing tests for all the functionality and then write the tests. That's not what even the most die-hard TDD advocates do.

I think many people here (like me) clicked through to read a well-reasoned article about how TDD enthusiasm may have gone too far, but sadly, this isn't that.

HN readers would do well to just move on, and the author would probably be well served by the advice of some of the commenters on his blog to take this post offline.

Post reply on HN