3 ms·

We 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 ver

We 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. Your code should have tests. It would be crazy not to 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?). [0] https://en.wikipedia.org/wiki/Test-driven_development https://en.wikipedia.org/wiki/Test-driven_development

salviati 1y ago
> 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.
- godelski 1y ago
  TDD doesn't mean "code has tests". It means you write tests and then writing code to pass those tests. It would be crazy for your code to not have tests... https://en.wikipedia.org/wiki/Test-driven_development https://en.wikipedia.org/wiki/Test-driven_development
cjfd 1y ago
We realize that test driven development has a refactoring step, right? Science can happen there if the practitioner is smart enough.
- godelski 1y ago
  That doesn't quite sound like TDD. I guess it could be. Are tests driving your code or are tests part of your code checking process? In science we definitely don't let tests drive. You form a hypothesis, then you test that. But this is a massive oversimplification because there's a ton that goes into "form a hypothesis" and a ton that goes into "test that". Theory is the typical driver. The other usual one being "what the fuck was that", which often then drives theory but can simultaneously drive experimentation. But in those situations you're in an exploratory phase and there are no clear tests without the hypotheses. Even then, tests are not conclusive. They rule things out, not rule things in.
dgb23 1y ago
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).
- godelski 1y ago
  You and I are in agreement for the most part. Especially steps 1-2 are not things easy to hand off in the first place. Step 6 it's important: reflect on your work and challenge it. I'm distinguishing this from 4 because you need to take the part of a strong adversary. I'm not quite sure this is hire evolutionary programs work, having written plenty myself. I'd lean on no. I'm certain this is not the fill of my work as a researcher. As a researcher you can't just put ideas together and follow some algorithm. There's no clear way to continue except in the incremental works. Don't get me wrong, those can do a lot of good, but they'll never get you anything groundbreaking. To do really novel things you need to understand details of what went on before. It's extremely beneficial to reproduce because you want to verify. When doing that you want to look carefully at assumptions and find what you're taking for granted. Maybe that's step 1 for you but step 1 is ongoing. The vast majority of people I meet fail to check their assumptions at even a basic level. Very few people want to play that game of 20 questions over and over being highly pedantic. Instead I hear "from first principles" and know what's about to follow is not a set of axioms. Carl Sagan bakes a pie from first principles. That's too far tbh, but you should probably mill your own flower (and that's still a long way from first)
pydry 1y ago
>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.
- godelski 1y ago
  I'm not sure what you're describing, but it kinda sounds like you're saying your using tests, not doing TDD. Having tests is very different than doing TDD
  - pydry 1y ago
    No, I do TDD almost exclusively. The reason it fails for some people is the way they test though. Having tests is pretty obviously different from TDD.

salviati 1y ago

> 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.

godelski 1y ago
TDD doesn't mean "code has tests". It means you write tests and then writing code to pass those tests. It would be crazy for your code to not have tests... https://en.wikipedia.org/wiki/Test-driven_development https://en.wikipedia.org/wiki/Test-driven_development

cjfd 1y ago

We realize that test driven development has a refactoring step, right? Science can happen there if the practitioner is smart enough.

godelski 1y ago
That doesn't quite sound like TDD. I guess it could be. Are tests driving your code or are tests part of your code checking process? In science we definitely don't let tests drive. You form a hypothesis, then you test that. But this is a massive oversimplification because there's a ton that goes into "form a hypothesis" and a ton that goes into "test that". Theory is the typical driver. The other usual one being "what the fuck was that", which often then drives theory but can simultaneously drive experimentation. But in those situations you're in an exploratory phase and there are no clear tests without the hypotheses. Even then, tests are not conclusive. They rule things out, not rule things in.

dgb23 1y ago

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).

godelski 1y ago
You and I are in agreement for the most part. Especially steps 1-2 are not things easy to hand off in the first place. Step 6 it's important: reflect on your work and challenge it. I'm distinguishing this from 4 because you need to take the part of a strong adversary. I'm not quite sure this is hire evolutionary programs work, having written plenty myself. I'd lean on no. I'm certain this is not the fill of my work as a researcher. As a researcher you can't just put ideas together and follow some algorithm. There's no clear way to continue except in the incremental works. Don't get me wrong, those can do a lot of good, but they'll never get you anything groundbreaking. To do really novel things you need to understand details of what went on before. It's extremely beneficial to reproduce because you want to verify. When doing that you want to look carefully at assumptions and find what you're taking for granted. Maybe that's step 1 for you but step 1 is ongoing. The vast majority of people I meet fail to check their assumptions at even a basic level. Very few people want to play that game of 20 questions over and over being highly pedantic. Instead I hear "from first principles" and know what's about to follow is not a set of axioms. Carl Sagan bakes a pie from first principles. That's too far tbh, but you should probably mill your own flower (and that's still a long way from first)

pydry 1y ago

>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.

godelski 1y ago
I'm not sure what you're describing, but it kinda sounds like you're saying your using tests, not doing TDD. Having tests is very different than doing TDD
- pydry 1y ago
  No, I do TDD almost exclusively. The reason it fails for some people is the way they test though. Having tests is pretty obviously different from TDD.