Automated QA and Testing with AI(antirez.com)
13 pointsby Chrisszz8 hours ago3 comments
  • 3192875an hour ago
    AI written as opposed to the authentic blog when this person still was a programmer.

    He'll find that no one wants the new Redis vibe coded features that have to be propped up by blog posts. When it matters, people chose real software.

  • wrxd5 hours ago
    I believe this can work if done on top of traditional testing. I would feel very uneasy to replace deterministic (ok, not always but mostly) test suites with something that is not deterministic at all
    • simianwords5 hours ago
      I think this is just TDD or unit test dogma and I’m personally not a fan.

      Unit tests and deterministic tests are hard to get right and need to be done at the correct boundary.

      I have seen many people dogmatically pushing unit tests religiously but this often leads to very hard to maintain tests that mostly exist just to change along with the main code itself.

      A good way to understand if your unit tests are good: are you changing them along with changing your actual code? Then it’s a bad test. I think the argument for “it’s just documentation” is weak.

      • fcarraldo2 hours ago
        I don’t disagree with your point, but there is still value in having unit tests that change along with the code. It’s less than a “proper” test, but when these tests break _unexpectedly_, it’s still more signal than you’d have without them. Like, always changing `file.go` alongside `file_test.go` may be acceptable if you catch errors that impact `serve_test.go` unexpectedly.

        Of course, if you’re just watching Claude changing both and saying “LGTM” then it’s not very valuable.

  • simianwords5 hours ago
    Scenario testing is the new word for it and I think this is a game changer.

    Two of the reasons I never liked writing tests is

    - they didn’t seem to usually assert much internal logic

    - they would have to be maintained along with the original code

    I think scenario testing is much better instead because the actual way a person uses a feature hardly changes but the internals might change a lot.

    So imagine I’m making an e-commerce website. There are lots of internal mechanisms. I’ll have an agent testing all the functionalities as if it were a customer. This gives me much much more confidence while writing code because it is more uncorellated with the code.

    Tomorrow I can change a lot of internals but the testing agent stays the same.

    There’s something to note though: not all code is possible to be scenario tested. Like data engineering and other things where the feedback time is huge.