Hacker News Reader

Comment by anthonypasq | Hacker News Reader

if your tests cover the acceptance criteria as defined in the ticket, why is all htat other stuff necessary?

Acceptance criteria are often buggy themselves, and require more context to interpret and develop a solution.

If you don't have sufficiently detailed acceptance criteria, how can anyone be expected to write code to satisfy them?

That's why you have to start with specifications. See, e.g., https://martinfowler.com/articles/exploring-gen-ai/sdd-3-too...

I wonder how many more times we'll rebrand TDD (BDD, SDD)?

Just 23 more times? ADD, CDD, EDD, DDD, etc.

Or maybe more?! AADD, ABDD, ACDD, ..., AAADD, AABDD, etc.

BDD is different, it is a way of gathering requirements.

As is, SDD it is some sort of AI nonsense.

Developers who aren't yet using AI would benefit from specs as well. They're good to have whether it's you or an LLM that's writing code. As a general rule, the clearer and less ambiguous the criteria you have, the better.

BDD was trying to recapture what TDD was originally, renamed from TDD in an effort to shed all the confusion that surrounded TDD. Of course, BDD picked up all of its own confusion (e.g. Gherkin/Cucumber and all that ridiculousness). So now it is rebranded as SDD to try and shed all of that confusion, with a sprinkle of "AI" because why not. Of course, SDD already is clouded in its own confusion.

Testing is the least understood aspect of computer science and it turns out that you cannot keep changing the name and expect everyone to suddenly get it. But that won't stop anyone. We patiently await the next rebrand.

thats impossible. Bugs are defined as when the code does not match the acceptance criteria.

If your acceptance criteria state something like “produces output f(x) for any inout x, where f(x) is defined as follows: […]”, then you can’t possibly test that, because you can’t test all possible values of x. And if the criteria don’t state that, then they don’t cover the full specification of how the software is expected to behave, hence you have to go beyond those criteria to ensure that the software always behaves as expected.

You can’t prove that something is correct by example. Examples can only disprove correctness. And tests are always only examples.

Because AC don’t cover non-functional things like maintainability/understandability, adherence to corporate/team standards etc.

Reply on news.ycombinator.com