5 ms·
There's a catch with 100% coverage. If the agent writes both the code and the tests, we risk falling into a tautology trap. The agent can write flawed logic and
by KurSix 10mo ago
There's a catch with 100% coverage. If the agent writes both the code and the tests, we risk falling into a tautology trap. The agent can write flawed logic and a test that verifies that flawed logic (which will pass).
100% coverage only makes sense if tests are written before the code or rigorously verified by a human. Otherwise, we're just creating an illusion of reliability by covering hallucinations with tests. An "executable example" is only useful if it's semantically correct, not just syntactically
- notimetorelax 10mo agoYou’re right. What I like doing in those cases is to review very closely the tests and the assertions. Frequently it’s even faster than looking at the SUT itself.
- ruszki 10mo agoI heard this “review very closely” thing many times, and rarely means review very closely. Maybe 5% of developers really do this ever, and I probably overestimate it. When people send here AI generated code, it’s quite obvious that they don’t review code properly. There are videos when people recorded how we should use LLMs, and they clearly don’t do this.
- christophilus 10mo agoYeah. This is me. I try, but I always miss something. The sheer volume and occasional stupidity makes it difficult. Spot checking only gets you so far. Often, the code is excellent except in one or two truly awful spots where it does something crazy.
- eru 10mo agoWell, we let humans write both business logic code and tests often enough, too. Btw, you can get a lot further in your tests, if you move away from examples, and towards properties.
- jaynetics 10mo agoCan you give an example (pun not intended) of testing with properties?
- deleted 10mo ago[deleted]
- eru 10mo agohttps://fsharpforfunandprofit.com/series/property-based-testing/ https://fsharpforfunandprofit.com/series/property-based-test... is an entertaining intro. https://hypothesis.readthedocs.io/en/latest/ https://hypothesis.readthedocs.io/en/latest/ are the docs for one of the best property based testing libraries available in any language.
- smarx007 10mo agoI think the phase change hypothesis* is a bit wrong. I think it happens not at 100% coverage but at, say, 100% MC/DC test coverage. This is what SQLite and avionics software aim for. *has not been confirmed by a peer-reviewed research.
- cloudhead 10mo agoWhat's MC/DC?
- Antibabelic 10mo agohttps://en.wikipedia.org/wiki/Modified_condition/decision_coverage https://en.wikipedia.org/wiki/Modified_condition/decision_co...
- emoII 10mo agoBasically branch coverage but also all variations of the predicates, e.g. testing both true || true, and true || false
- zweifuss 10mo agoModified Condition/Decision Coverage It's mandated by DO-178C for the highest-level (Level A) avionics software. Example: if (A && B || C) { ... } else { ... } needs individual tests for A, B, and C. Test #,A,B,A && B,Outcome taken,Shows independence for 1,True,True,True,if branch,(baseline true) 2,False,True,False,else branch,A (A flips outcome while B fixed at True) 3,True,False,False,else branch,B (B flips outcome while A fixed at True)
- zweifuss 10mo agoI made a mistake: Test # A B C Result 1 True True False True 2 False True False False 3 True False False False 4 False True True True
- deleted 10mo ago[deleted]
- machomaster 10mo agoYou could mitigate that risk by using different agents (versions, companies).
- ben_w 10mo agoAll the problems you list are true, but the solutions not so much. I've seen this problem with humans even back at university when it was the lecturer's own example attempting to illustrate the value of formal methods and verification. I would say the solution is neither "get humans to do it" nor "do it before writing code", but rather "get multiple different minds involved to check each other's blind spots, and no matter how many AI models you throw at it they only count as one mind even when they're from different providers". Human tests and AI code, AI tests and human code, having humans do code reviews of AI code or vice-versa, all good. Two different humans usually have different blind spots, though even then I've seen some humans bully their way into being the only voice in the room with the full support of their boss, not that AI would help with that.
- melagonster 10mo agoMaybe this is because humans have good intuition to know the difference between us. But this type of intuition does not work on the behaviour of LLMs.
- godelski 10mo ago> "get multiple different minds involved to check each other's blind spots This is actually my big gripe about chatbot coding agents. They are trained on human preference and thus they optimize for errors that are in our blind spots. I don't think people take this subtly seriously enough. Unless we have an /objective/ ground truth we end up proxying our optimization. So we don't optimize for code that /is/ correct, we optimize for code that /looks/ correct. It may seem like a subtle difference but it is critical. The big difference is when they make errors they are errors that are more likely to be difficult for humans to detect. Good tools should complement tool users. Fill in gaps. But as we've been trying to train agents to replace humans we are not focusing on this distinction. I want my coding agent to make errors that are obvious to me just as I want errors I make to be obvious to it (or for it to be optimized to detect errors I make)
- KurSix 9mo agoExactly, we've basically trained an army of perfect corporate suck-ups. AI optimizes for the "least resistance at review" metric, not "logic correctness," so relying on eyeballs to check AI code right now is risky, we need "unfeeling" validators: compilers, formal verification, and rigid tests
- joshribakoff 10mo agoThat’s why you’ve gotta test your tests. Insert bugs and ensure they fail. As the sibling comments alluded to, it’s not exclusively an AI problem since multiple people can miss the issue too. It’s wonderful that AI is an impetus for so many people to finally learn proper engineering principles though!
- vrighter 10mo agobut who will test the tests of tests?
- Supermancho 10mo agoThe double entry technique is the most effective path to ensure accuracy (best tradeoffs for time vs accuracy) in finance and software. ie Triple book accounting has not been the standard because it's a bad tradeoff. It requires a large increase in time and effort, for rare increases in accuracy.
- adrianN 10mo agoThe mutation testing engine.
- deleted 10mo ago[deleted]
- godelski 10mo agoJust add tests to test your test tests
- KurSix 9mo agoMutation testing is becoming the only way to catch AI red-handed. Without mutations you'll be staring at a perfect CI/CD dashboard, unaware that your tests verify absolutely nothing Yeah, it burns CPU like crazy, but CPU time is dirt cheap right now compared to the cost of an engineer debugging that self-deception in production
- theptip 10mo agoIt’s true - but there are “good code” solutions to this already. For example, BDD / Acceptance Tests can be used to write human-readable specs. IMO it’s quite boilerplate-y to set this up pre-LLM but probably the ROI is favorable now. Furthermore, as Uncle Bob has written a lot about, putting effort into structuring your tests well is another area that’s usually under-invested. LLMs often write very repetitive tests, but are happy to DRY out, write factories, etc if you ask them.
- dbdoskey 10mo agoIn theory, that is the benefit of having an agent that is limited to only doing the tests, and an agent that only does the coding, and have them run separately, that way to fix a test, you don't change the test, etc...
- closeparen 10mo agoAlso true of human-written unit tests. You probably also want to have integration or UI automation tests that cover the end-user scenarios in your product requirements, and invariants that are checked against large numbers of examples either taken from production (sanitized of course), in a shadow environment, or generated if you absolutely must.
- eternityforest 10mo agoTests freeze behavior in place, and manual end to end testing can confirm that the most common paths are at least kind of correct ish. Obviously that's not good enough, but I'd much rather have AI tests than poor test coverage.