4 ms·

>You test case is more useless than a turd in the middle of the dining room table unless you put a comment in front of it that explains what it assumes, what it

>You test case is more useless than a turd in the middle of the dining room table unless you put a comment in front of it that explains what it assumes, what it attempts, and what you expect to happen as a result. This is why I found Gherkin/Cucumber (and BDD in general) to be a total revelation when I first encountered it. No one should be writing tests any other way IMO. https://cucumber.io/docs/gherkin/reference/ https://cucumber.io/docs/gherkin/reference/

invalidname 4y ago
This sounds like a good theory but the practice of it is really hard. Pretty quickly you end up with tests that "say" one thing but have nuanced different behavior in the underlying implementation. Then try to debug a "document"... I like the idea. But having tried it at scale, it becomes a mess. Code I can understand. I can read English comments. I can't debug English.
- deleted 4y ago
  [deleted]
- brabel 4y ago
  We have it at scale, and no, it doesn't become a mess. We use Spock, which make "comments" a very expected thing, which helps us not let tests without comments pass a code review. Just use a tool that helps you and stop writing stupid tests whose impl code looks worse than the code being tested.
- urthor 4y ago
  https://www.scalatest.org/at_a_glance/WordSpec https://www.scalatest.org/at_a_glance/WordSpec Seems pretty straightforward.
  - invalidname 4y ago
    Then why all the comments? I know what typical code does. This code looks simple but that's misleading when you're trying to understand a failure. You want consistency and clarity. You want readablity like code is readable not like a book is readable.
randomdata 4y ago
Gherkin/Cucumber reintroduce the very problem TDD/BDD was intended to solve: Documentation falling out of sync with the implementation. The revelation of TDD, which was later rebranded as BDD to deal with the confusion that arose with other types of testing, was that if your documentation was also executable the machine could be used to prove that the documentation is true. The Gherkin/Cucumber themselves are not executable and require you to re-document the function in another language with no facilities to ensure that the two are consistent with each other. If you are attentive enough to ensure that the documentation and the implementation are aligned, you may as well write it in plain English. It will give you all of the same benefits without the annoying syntax.
- sirsinsalot 4y ago
  TDD wasn't rebranded BDD. BDD is a QA concern, primarily used for QA tests against a written (BDD) requirement. TDD is about unit testing, which is about testing the implementation BY developers FOR other developers. TDD says nothing about the correctness of the software against a spec, only that a given implementation aligns with a developer's intention.
  - BerislavLopac 4y ago
    If unit tests are not testing the behaviour, it's being done wrong. If they are, the only difference between TDD and BDD is where, in which form, and by whom is that behaviour defined.
    - sirsinsalot 4y ago
      Unit tests assert implementation behaviour to aid refactoring. If developers misunderstand the spec, the unit tests can be valid. They don't assert developer understanding. Say it with me, unit tests are to aid refactoring. If we mix QA and implementation details just because both sides use the word "test" it ends in trouble. QA should be blind to unit test coverage or even usage at all, they're totally independent concerns. A passing unit test says nothing against correctness of product against a spec or design... only that it works and continues to work as a developer intended, to aid the work of future developers, even if they misunderstood the spec. Your comment is at the core of why QA is a total mess. Everyone is confused about what "test" means in different contexts. Why have a QA function at all with 100% unit test coverage? Because the unit tests may encode misunderstanding by developers. They're there to fight entropy, not wrongness. QA, using BDD and other tools, ensure the product is correct, regardless of how well it fights entropy by unit tests.

invalidname 4y ago

This sounds like a good theory but the practice of it is really hard. Pretty quickly you end up with tests that "say" one thing but have nuanced different behavior in the underlying implementation. Then try to debug a "document"... I like the idea. But having tried it at scale, it becomes a mess. Code I can understand. I can read English comments. I can't debug English.

deleted 4y ago
[deleted]
brabel 4y ago
We have it at scale, and no, it doesn't become a mess. We use Spock, which make "comments" a very expected thing, which helps us not let tests without comments pass a code review. Just use a tool that helps you and stop writing stupid tests whose impl code looks worse than the code being tested.
urthor 4y ago
https://www.scalatest.org/at_a_glance/WordSpec https://www.scalatest.org/at_a_glance/WordSpec Seems pretty straightforward.
- invalidname 4y ago
  Then why all the comments? I know what typical code does. This code looks simple but that's misleading when you're trying to understand a failure. You want consistency and clarity. You want readablity like code is readable not like a book is readable.

randomdata 4y ago

Gherkin/Cucumber reintroduce the very problem TDD/BDD was intended to solve: Documentation falling out of sync with the implementation. The revelation of TDD, which was later rebranded as BDD to deal with the confusion that arose with other types of testing, was that if your documentation was also executable the machine could be used to prove that the documentation is true. The Gherkin/Cucumber themselves are not executable and require you to re-document the function in another language with no facilities to ensure that the two are consistent with each other. If you are attentive enough to ensure that the documentation and the implementation are aligned, you may as well write it in plain English. It will give you all of the same benefits without the annoying syntax.

sirsinsalot 4y ago
TDD wasn't rebranded BDD. BDD is a QA concern, primarily used for QA tests against a written (BDD) requirement. TDD is about unit testing, which is about testing the implementation BY developers FOR other developers. TDD says nothing about the correctness of the software against a spec, only that a given implementation aligns with a developer's intention.
- BerislavLopac 4y ago
  If unit tests are not testing the behaviour, it's being done wrong. If they are, the only difference between TDD and BDD is where, in which form, and by whom is that behaviour defined.
  - sirsinsalot 4y ago
    Unit tests assert implementation behaviour to aid refactoring. If developers misunderstand the spec, the unit tests can be valid. They don't assert developer understanding. Say it with me, unit tests are to aid refactoring. If we mix QA and implementation details just because both sides use the word "test" it ends in trouble. QA should be blind to unit test coverage or even usage at all, they're totally independent concerns. A passing unit test says nothing against correctness of product against a spec or design... only that it works and continues to work as a developer intended, to aid the work of future developers, even if they misunderstood the spec. Your comment is at the core of why QA is a total mess. Everyone is confused about what "test" means in different contexts. Why have a QA function at all with 100% unit test coverage? Because the unit tests may encode misunderstanding by developers. They're there to fight entropy, not wrongness. QA, using BDD and other tools, ensure the product is correct, regardless of how well it fights entropy by unit tests.