alt Hacker NewsWe realize test driven development doesn't work, right? Any scientist worth... any salt will tell you that fitting data is the easy part. In fact, there's a very famous conversation between Enrico Fermi and Freeman Dyson talking about just this. It's something we've known about in physics for centuries
Edit:
Guys, I'm not saying "no tests", the "Driven Development" part is important. I'm talking about this[0].
| Test-driven development (TDD) is a way of writing code that involves writing
| an automated unit-level test case that fails, then writing just enough code
| to make the test pass, then refactoring both the test code and the production
| code, then repeating with another new test case.
But tests can't be the end all be all. You gotta figure out if your tests are good, try to figure out where they fail, and all that stuff. That's not TDD. You figure shit out as you write code and you are gonna write new tests for that. You figure out stuff after the code is written, and you write code for that too! But it is insane to write tests first and then just write code to complete tests. It completely ignores the larger picture. It ignores how things will change and it has no context of what is good code and bad code (i.e. is your code flexible and will be easy to modify when you inevitably need to add new features or change specs?).
Replies
> We realize test driven development doesn't work, right?
What do you mean with this? I'm a software engineer, and I use TDD quite often. Very often I write tests after coding features. But I see a huge value coming from tests.
Do you mean that they can't guarantee bug free code? I believe everyone knows that. Like washing your hands: it won't work, in the sense you will still get sick. But less. So I'd say it does work.
We realize that test driven development has a refactoring step, right? Science can happen there if the practitioner is smart enough.
>But it is insane to write tests first and then just write code to complete tests. It completely ignores the larger picture. It ignores how things will change and it has no context of what is good code and bad code
If you TDD outside in and tend to test from the edges of your stack, being conservative about moving your test coupling lower down the stack then it provides you with the freedom to change things underneath the hood and still have a body of tests that let you know you didnt break anything.
If you TDD inside out then yes you can and probably will create an enormous inflexible mess of tests that dont tell you if your code worked.
Sadly many tutorials teach it as "you want to write a class "Ball" you should write a test for that class first" which is wrongheaded.
Thats just writing tests badly though, it's not intrinsic to red-green-refactor.
Test first programming has its use and can be quite peoductive.
I believe the issue with „TDD“ is the notion that it should drive design and more importantly that it‘s always applied. I disagree with both if those.
Given a problem where test first makes sense, I prefer roughly this procedure:
1. Figure out assumptions and guarantees.
2. Design an interface
3. Produce some input and output data (coupled)
4. Write a test that uses the above
5. Implement the interface/function
The order of 4 and 5 aren‘t all that important actually.
My experience is that an AI is pretty good at 3, at least once you defined one example, it will just produce a ton of data for you that is in large parts useful and correct.
Step 4 is very easy and short. Again, AI will just do it.
Step 5 is a wash. If it doesn‘t get it in a few tries, I turn it off and implement myself. Sometimes it gets it but produces low quality code, then I often turn it off as well.
Step 1-2 are the parts that I want to do myself, because they are the significant pieces of my mental model of a program.
I believe this is also how evolutionary/genetic programs usually work if you squint. They operate under a set of constraints that are designed by a human (researcher).