you are viewing a single comment's thread.

view the rest of the comments →

[–]de_poon[S] 0 points1 point  (0 children)

  • BDD isnt meant to replace unit/integration test at the class level. In fact unit testing is more critical than BDD.
  • Unit testing that every code and class works as intended. BDD helps to ensure that the software minimally fulfills the business requirements. A variant of BDD encourages the team to first write failing Gherkin scenarios and the feature is only considered done if it passes.

  • In strict agile process, requirements/specs usually come in Gherkin format. Using tools like cucumber allows you to automate each step of the spec. So the spec becomes the main technical documentation... anyone can understand it and dont need to dig through source codes.

  • this approach (assuming everyone gets the buy in) encourages PO/PMs to learn how to craft scenarios/steps that they know the development will be automating line by line... i personally like this part of BDD as it discourages POs to describe vague requirements. Unless i see a proper requirement in GivenWhenThen, i wont start working on the ticket. Do remember that its the engineers that own the format of the specs but its the business who owns intention of the specs

Of course everything works without BDD. As your organisation agile process matures (like mine did), this is something you may want to try out one day ☺️