Test-driven development: A great idea hiding behind a terrible implementation?

TDD is awesome when fixing bugs (as opposed to writing features), when writing straight up business logic (especially when there are a lot of edge cases) and when you know exactly how something is going to work.

It's really bad when doing anything that requires exploration and research (which is the example in the article).

Regurgitating others' opinions and making multiple unfounded assertive statements is key to demonstrating he has already mastered the software domain.

I guess the suitability of TDD depends on how much a feature involves "how" rather than "what": Whenever it is clear what the feature should do (and what the feature's interface looks like) and the implementation is only about the "how", TDD seems to a very good idea. Almost every compiler-related task falls into this category. I just wrote a blog article on how to implement Typescript refactorings using TDD ([1]) and I don't think anyone could argue against using TDD there.

If the feature is more about "what" (like UI/UX), TDD seems to be more of a burden than an useful asset.

[1] https://blog.hediet.de/post/implementing_typescript_refactor...

TDD ensures this as there is no implementation yet when you write the tests.

It also implies the changing requirements comes with the overhead of changing the corresponding tests. This is what happened in the incident described in the article. In many cases development speed might be more important than test coverage.

Still worse are tests derived from the implementation (usually to boost done coverage metric) because they often break although the code fulfills the requirements.

Rule of thumb: Test only the requirements which are stable.

why must software engineering be mainly opinion-based? Why can't we have objective facts, or at least only talk about objective facts without going out asserting one's opinions as truth?

AFAIK other engineering disciplines do not suffer from this problem as much as software engineering. This really bugs me.

While my dev approach is more about think, think, think harder, code, compiler barely complains, fix small issues, write test, done.

TDD felt very uncomfortable because the thinking part didn't seem to be emphasized much. It's like keep going, you iterate again real soon in this code, now again, and again.

Maybe I got it wrong, I don't know. But I share the author's frustration.

Yeah no. You have been instructed poorly. It's not your fault.

Yes, you have to think about things, but that's not the real purpose of TDD. Just like making a good design, it's a side effect.

Straight coding is doing it backwards, as odd as that sounds. The reason is that the computer never lies, but it's really, really easy to lie to yourself, forget things, misunderstand your own variable names, and so on. When you're coding, you'll make all kinds of errors. The computer will not. So wouldn't it be better to have the computer constantly checking on you to see if you're making any new errors? Better still, not only will it check on you, it'll check on everybody else who touches the code too.

There are domains in which TDD does not make sense. Exploratory coding, like you'd do in startups, for instance. Small pure functional code. Academic learning. In each of these cases you are still doing TDD, it's just you're not coding the tests. You never get away from TDD, you just sometimes hide it or pretend it isn't happening. There's a test, it fails, you write code to make it pass.

In other cases, such as any non-trivial mutable OO commercial code that is going to be around for a while, not using TDD is malpractice. Whatever small hit you may take on initial productivity is insignificant compared to the endless amount of money you may spend later on maintenance.

Plus, I'm not so sure it's inefficient to begin with. Instead, I think a lot of coders code in an inefficient way writing code that is difficult or impossible to test. Once you start using TDD, you're going to have to come to terms with that and un-fuck your code. That's probably going to suck. Best to do it earlier rather than later. (Long discussion here about what to do with legacy codebases)

I think TDD does shine for some things, it especially shines for refactors (where the tests ideally shouldn't change anyway) or bug-fixing where you can write in a test to catch the bug that has been found as a regression test before starting to fix the bug.

For brand new features it is a signifincant discomfort. I concede that that discomfort can result in more thought-through code but it can also just put off the implementer into not working as efficiently as they would be able to in a 'code first, then refactor' mindset.

So every line of code you are writing has to have a purpose, and later on when you are fixing a bug or adding something new, you are making sure, you didn’t break any previous functionality.

I think one of the biggest values of TDD is it teaches developers how to write unit testable code, which, if you are new to unit testing, can be quite hard to get your head around.

As for its usefulness in ‘real-life’, I’m going to answer with a solid ‘it depends’.

Anyone who dismisses it is missing out on some potential big advantages, anyone who is a 100% TDD zealot is probably either wasting time or lacks extensive real world experiance.

And In 7+ years of engineering at FAANG companies, I've never once had clear requirements before the software was complete (let alone started).

1. Tests can be unit-test, integration-test, e2e tests. Don't limit yourself.

2. TDD is a technique. Depending on the problem and your experience it might not be the right one to efficiently get you a working program and a good test suite.

Remember there is no free lunch.

3. Also, if you have never successfully applied TDD: Please stand stil for a moment. Some techniques require practice and TDD is one of those.

You need to invest time in order to use it efficiently. Once you do it, you will be faster and deliver higher quality code for a large set of programming tasks.

4. There are tasks where i don't use TDD. However, I usually go back to it as soon as I can. You can switch between the two techniques. There is not one way that is most correct.

5. Also, note: if you don't write tests first. Writing tests after the code is complete is more difficult. You might need to adapt your code to make it testable.

6. If you write tests afterwards, usually you will accidentally omit tests for crucial cases if you are not careful. I use line coverage and branch coverage tools to help me when I don't develop test driven.

Sometimes the right thing to do is TDD, sometimes the right thing to do is to ssh into a production server and modify a Perl script.

  (1) install database (or point to dev,) configure app, run seed data. 
  (2) creating the state in the database manually. 
  (3) change lines of code for feature
  (4) reloading app, navigating through to the feature state, manually verifying. 
  (5) fix runtime errors or bugs
  (6) Repeat as needed. Commit.

I think TDD at the very least is a education/comprehension exercise in abstract thinking which will discourage scenarios like the one described above. Once someone is able to TDD and 'gets it' then sometimes the way they approach arranging code even without TDD is better. I think this is why we may have mixed messages like "TDD is great!.. but we don't practice it at work."

Using a test harness any sorts to test something in isolation will speed things up. We can better understand where a module begins and ends (i/o, side-effects.) Develop it rapidly in the harness and then a few (automated) integration tests at the end. It doesn't have to be a TDD-specific testing harness.

React Storybook is an example of a UI test harness. It's still manual testing, but we get that great separation-of-concerns goodness that makes for better designed (and easier to maintain) systems.

Case in point: you don't have to write your tests first. You can write a quick spike first to feel out you API, then rewrite that code with TDD.

Why is this dude so desperate to have this function written quickly? This whole episode could not have taken more than 20 minutes. Sloppiness is the enemy with software development.

"But in real life, features are way more complex than Function X should take a name and output a greeting with that name. Often times the product request will change mid-work, or you’ll realize that the feature can’t work as requested. Maybe your original understanding was flawed and you have to start over."

Smoking gun right here. This is just wrong and stinks of amateur. Features are almost always made of many small functions that do little bits of easily tested work. And if you factor you code well, which is a large benefit of TDD: having well factored code, changes should not collapse you whole sand castle. If that is happening, maybe go back to school. Oh wait, you never went to school, just a 4 week course so you can have low level programming job to toil at...

What he is missing here is the alternative: a big ball of mud with giant functions and poor tests to validate behavior.

However, there's a myriad of other problems TDD doesn't help you, like when you need to design a system beforehand or you want to make an educated jump to a solution that's good enough and you already know it.

This is the most popular method of doing things in my experience and the reason for that seems to be it makes chronological sense to a human brain. It’s very unnatural for people (including clever devs) to consider a project like manufacturing a car and starting with ‘the tire pressure should be correct’. Also too often (wrongly or rightly) prototypes often don’t have tests and that sets the tone quite early. Automated tests should be written ASAP no matter which methodology is used.

I don't like brittle tests that are specific to the implementation, such as assert that such-and-such isn't invoked--an equivalent function can be invoked and pass.

The order I do things:

  - think about the problem space, come up with some shape(s)
  - list the test cases, but don't write the bodies
  - code the happy path and runtime errors for others
  - write the test bodies, make them pass
  - clean-up any remaining placeholders

I'd imagine that TDD is good when you know exactly what the requirement that the project has. i.e. TDD is good in the implementation phase but not the design phase. In the design phase, you often don't know exactly what the problem really is, so you need to keep things as loose as possible because you're going to experiment. I imagine that in many small business scenarios these two phases are often fused together, so TDD wouldn't appeal that much for them.

Anything you write as an engineer has to be tested. Manual testing is way slower than automated testing.

I find that when I have a few good automated tests in place, especially in browser selenium tests, I save literally days of work of manual testing. Thats time that I can use to build more features, get more feedback on my product or do other more productive things than manual testing.

10 minutes of time writing a good test saves me days of work in the future testing new changes. Writing good tests is a high impact, time saving investment.

I think this is the crux of what the authour is trying to say. Not necessarily a criticism of TDD, but rather a criticism of holding to a particular belief no matter the circumstances. Of being inflexible.

When designing an interface I like to write usage examples. They're more nimble to work with than tests who require scaffolding. The usage examples do tend to become tests during implementation.

It's dumb to do that when you still don't have the characteristics of the space where you are building or the materials available, but it's dumb not to do it when you know exactly what and how you are building it.

In the same way, it's dumb not to do it when you have already a building and you are going to start to change things.

I think the problem is that, being all information, in programing those phases look the same but they are actually very different.

What came first the chicken or the egg?

Either the test came first and the code after or the code came first and test after.

An issue can arise in fast agile test driven development environments if you develop the code first and then do not get time to do the tests. If you start with the test you will be ensured to have time to write code otherwise the software will not work.

"The muscle doesn't see what you're holding in your hands." Arnold Schwarzenegge - The tests doesnt care how you got them in place

The rush to produce code, now, is making working in this industry suck.

Just having an understanding of TDD and holding it as an aim will ultimately result in a better, more maintainable codebase.

So what's the downside?

I note some people here are talking about things that require exploration and research as a counter-inducation. Well, maybe in some cases but certainly not in all. One could also start with a test at a relatively high level and then do the exploration while writing code to make it pass. In that case one would write more code to make it pass than would be normal but it still benefits from being in the TDD cycle. After having it basically working one does additional TDD cycles to iron out the cases where it would go wrong.

The main benefits of starting out with a test is that: 1) tests do cost time so you need to recoup that by going faster in other parts of development. If you start out with the test it immediately starts paying back when it flags your first attempt at an implementation as either passing or failing. 2) The fact that the test first should fail and fail in a particular way tells you whether your thinking about how the system works is actually correct. It is like bringing the scientific method to programming. People in practice very often have just the wrong idea of how something works in the first place.

People are also talking about TDD being a strange order to think about programming. This is also my experience. It requires some getting used to. It is quite good though. The point being that it enables one to not need to think about everything at the same time. When writing a test you think about the functionality you need. When writing an implementation you think about algorithms and when refactoring you think about code quality. In traditional development this gets rolled up in one big ball of mud which makes the thinking about either of these three aspects of lower quality.

One thing that people get into trouble with is trying to write test for functionality that is too low level and therefore very much implementation defined and therefore subject to change. I think one should generally work at a level where one tests the behavior of a cluster of a few classes. This problem also leads to tests that are too trivial. If one has a method that adds n to m and one writes a test for that one is testing that the processor really can add numbers and that is not very interesting.

Kent Beck, DHH and Martin Fowler explain it very nicely in the "Is TDD Dead?" dicussion: https://martinfowler.com/articles/is-tdd-dead/

I highly recommend it to everyone even if you think you understand what is TDD all about! It's a very deep, interesting discussion about TDD between truly great minds.

IMHO only thing dumb is developing without testing

25 minutes, 16 points - all that it takes?

The sharpest engineers I know distinguish themselves mostly by how rarely they resort to running code at all. Instead they seem to have a mental model of the code base they are working on, similar to that of a mathematician. They can write code for days, weeks (or even months) and just know it will mostly work once they run it.

TDD is a method.

TDD forces you be clear about what the result of your code should be before you start coding. It also ensures that there is a test to check your code. This is certainly not dumb.

You will write tests anyway (right?) so it does seem smarter and more effective to write them first in the same way as you write requirements first before writing code. Nothing prevents you from iterating as progress and discover corner cases, for example.

People who say that TDD moves slower are simply admitting that they don't test. Automated tests are also crucial because 99% of testing is regression testing and that obviously cannot be done manually every time the code changes.

I found it rather ironic that the article ends by praising behaviour-driven development, which is an extension of TDD...