5 ms·

> Then, just wait a few months and then rerun the code generation with a new version of the AI and the code will be better. How many times have you seen a code

> Then, just wait a few months and then rerun the code generation with a new version of the AI and the code will be better. How many times have you seen a code change that “passed all the tests” take down production or break an important customer’s workflow? Usually that was just a relatively small change. Now imagine that you regenerated literally all the code. The code is the spec. Any other spec comprehensive enough to cover all possible functionality has to be at least as complex as the code.

wonnage 1y ago
TDD is testing in production in disguise. After all, bugs are unexpected and you can’t write tests for a bug you don’t expect. Then the bug crops up in production and you update the test suite.
- embedding-shape 1y ago
  TDD has always been about two things for me; be able to move forward faster because I have something easy to execute that compares it against the known wanted state, and in the future preventing unwanted regressions. I'm not sure I've ever thought of unit testing as "prevent potential future bugs", mostly up front design prevents that, or I'd use property testing, but neither of those are inside the whole "write test then write code" flow.
  - Retric 1y ago
    The intended workflow of TDD is to write a set of tests before some code. The only reason that makes sense conceptually is to prevent possible future bugs from going undetected. Put another way if your TDD always pass then there’s no point in writing them, and there’s no known bugs before you have any code. So discovering future bugs that didn’t exist when you’re writing those tests is the point.
    - black_knight 1y ago
      I don’t really understand how to write tests before the code… When I write code, the hard part is writing the code which establishes the language to solve the problem in, which is the same language the tests will be written in. Also, once I have written the code I have a much better understanding as the problem, and I am in a way better position to write the correct tests.
      - numpy-thagoras 1y ago
        You write the requirements, you write the spec, etc. before you write the code. You then determine what are the inputs / outputs that you're taking for each function / method / class / etc. You also determine what these functions / methods / classes / etc. compute within their blocks. Now you have that on paper and have it planned out, so you write tests first for valid / invalid values, edge cases, etc. There are workflows that work for this, but nowadays I automate a lot of test creation. It's a lot easier to hack a few iterations first, play with it, then when I have my desired behaviour I write some tests. Gradually you just write tests first, you may even keep a repo somewhere for tests you might use again for common patterns.
        pjmlp 1y ago
        I want to have a CUDA based shader that decays the colours of a deformable mesh, based on texture data fetched via Perlin noise, it also has to have a wow look as per designer requirements. Quite curious about the TDD approach to that, espcially taking into account the religious "no code without broken tests" mantra.
        CuriouslyC 1y ago
        Break it down into its independent steps, you're not trying to write an integration test out of the gate. Color decay code, perlin noise, etc. Get all the sub-parts of the problem mapped out and tested. Once you've got unit tests and built what you think you need, write integration/e2e tests and try to get those green as well. As you integrate you'll probably also run into more bugs, make sure you add regression tests for those and fix them as you're working.
- enraged_camel 1y ago
  >> After all, bugs are unexpected and you can’t write tests for a bug you don’t expect. Ironically, AI can. In my experience it is extremely good at thinking about edge cases and writing tests to defend against them.

wonnage 1y ago

TDD is testing in production in disguise. After all, bugs are unexpected and you can’t write tests for a bug you don’t expect. Then the bug crops up in production and you update the test suite.

embedding-shape 1y ago
TDD has always been about two things for me; be able to move forward faster because I have something easy to execute that compares it against the known wanted state, and in the future preventing unwanted regressions. I'm not sure I've ever thought of unit testing as "prevent potential future bugs", mostly up front design prevents that, or I'd use property testing, but neither of those are inside the whole "write test then write code" flow.
- Retric 1y ago
  The intended workflow of TDD is to write a set of tests before some code. The only reason that makes sense conceptually is to prevent possible future bugs from going undetected. Put another way if your TDD always pass then there’s no point in writing them, and there’s no known bugs before you have any code. So discovering future bugs that didn’t exist when you’re writing those tests is the point.
  - black_knight 1y ago
    I don’t really understand how to write tests before the code… When I write code, the hard part is writing the code which establishes the language to solve the problem in, which is the same language the tests will be written in. Also, once I have written the code I have a much better understanding as the problem, and I am in a way better position to write the correct tests.
    - numpy-thagoras 1y ago
      You write the requirements, you write the spec, etc. before you write the code. You then determine what are the inputs / outputs that you're taking for each function / method / class / etc. You also determine what these functions / methods / classes / etc. compute within their blocks. Now you have that on paper and have it planned out, so you write tests first for valid / invalid values, edge cases, etc. There are workflows that work for this, but nowadays I automate a lot of test creation. It's a lot easier to hack a few iterations first, play with it, then when I have my desired behaviour I write some tests. Gradually you just write tests first, you may even keep a repo somewhere for tests you might use again for common patterns.
      - pjmlp 1y ago
        I want to have a CUDA based shader that decays the colours of a deformable mesh, based on texture data fetched via Perlin noise, it also has to have a wow look as per designer requirements. Quite curious about the TDD approach to that, espcially taking into account the religious "no code without broken tests" mantra.
        CuriouslyC 1y ago
        Break it down into its independent steps, you're not trying to write an integration test out of the gate. Color decay code, perlin noise, etc. Get all the sub-parts of the problem mapped out and tested. Once you've got unit tests and built what you think you need, write integration/e2e tests and try to get those green as well. As you integrate you'll probably also run into more bugs, make sure you add regression tests for those and fix them as you're working.
enraged_camel 1y ago
>> After all, bugs are unexpected and you can’t write tests for a bug you don’t expect. Ironically, AI can. In my experience it is extremely good at thinking about edge cases and writing tests to defend against them.