{"id":4412,"date":"2022-01-31T07:00:00","date_gmt":"2022-01-31T07:00:00","guid":{"rendered":"https:\/\/www.diogonunes.com\/blog\/?p=4412"},"modified":"2022-02-03T13:48:53","modified_gmt":"2022-02-03T13:48:53","slug":"testers-toolbox-6-dev-methodologies","status":"publish","type":"post","link":"https:\/\/www.diogonunes.com\/blog\/testers-toolbox-6-dev-methodologies\/","title":{"rendered":"Development processes (Toolbox #6)"},"content":{"rendered":"
\"\"
Photo by Annie Spratt<\/a> on Unsplash<\/a>
<\/figcaption><\/figure>\n
\n

tl;dr<\/strong> TDD, ATDD and BDD are different development practices that favour quality.<\/p>\n

\ud83c\udfc6 This post was featured in Software Testing Notes #44<\/a><\/p>\n<\/blockquote>\n

<\/p>\n

Theory<\/h2>\n

Neither of these methodologies are “testing” by itself. They are development practices that foster quality, which in turn make testing easier.<\/p>\n

TDD: (Unit) Test Driven Development<\/h3>\n
\n

Write unit tests<\/a> before writing the code that makes those tests pass.<\/p>\n<\/blockquote>\n

The TDD cycle can be summarised as “Red-Green-Refactor”. First, you write a set of unit tests that describe the code behaviour that you want to implement. If you run those tests, they will be failing (red), because that behaviour is not yet implemented. Second, you write the simplest code required to make those tests pass (green). If you wanted, you could stop here. Usually developers go a step further and improve that code to be more resilient and maintainable (refactor).<\/p>\n

Unit tests tell if the code does what the developer expected it to do, at the method level, in isolation from the rest of the codebase.<\/p>\n

ATDD: Acceptance Test Driven Development<\/h3>\n
\n

Write acceptance tests<\/a> before writing the code that makes those tests pass.<\/p>\n<\/blockquote>\n

The ATDD cycle follows the same “Red-Green-Refactor” from TDD. The difference is the type of test that is created in the “Red” step. In fact, the two methodologies can be used together, as Robert C. Martin<\/a> illustrates: “a developer runs the acceptance tests and notices what fails; then they write unit tests that force them to write the code that will make some small portion of the acceptance tests pass; they keep running the acceptance tests to see how much is working as expected, and they keep adding unit tests and code until all the acceptance tests pass”.<\/p>\n

Acceptance tests tell if the code does what the product\/client expected it to do, at the system level, in collaboration with the rest of the codebase.<\/p>\n

OID: Outside-In Development<\/h3>\n
\n

OID works by using automation tools combined with scenarios from a collaborative session to create a guide for Developers; this results in ensuring Developers develop what the business wants.<\/p>\n

\u2014 Mark Winteringham<\/a><\/p>\n

(\u2026) people started working outside-in<\/em>, from the User Interface (UI) through which users experienced the system’s behaviour, to the controllers, models, microservices (API), classes, etc., until they finally had working software that mattered to the stakeholders<\/p>\n

\u2014 Liz Keogh<\/a><\/p>\n<\/blockquote>\n

OID is starts similar to ATDD. Both methodologies start by specifying the behaviour of your system as seen from the outside (see black box testing<\/a>). These specifications tell developers what their code needs to accomplish.<\/p>\n

There’s a small difference though. OID is not so prescriptive about test automation as ATDD is. Listen to Mark Winteringham<\/a>: “The assumption from Testers is that because OID uses tools that are typically related to automated testing that must mean OID is automated testing. OID helps Developers design good code and deliver what the business really wants. Not deliver testing.”<\/p>\n

OID is less about technology and testing and more about process and collaborating; it was an evolutionary step<\/a> towards behaviour driven development.<\/p>\n

BDD: Behaviour Driven Development<\/h3>\n
\n

BDD in a nutshell: Using examples at multiple levels to create a shared understanding and reduce uncertainty to deliver software that matters.<\/p>\n

\u2014 Dan North, creator of BDD<\/p>\n<\/blockquote>\n

BDD is an OID methodology. It starts at the outside by identifying business outcomes, and then drills down into the features that will achieve those outcomes. It focuses heavily on conversations between different roles, using examples to clarify requirements, and describing those requirements in a language readable by all participants.<\/p>\n

\n

If you’re not having conversations, you’re not doing BDD. Order of importance: having conversations > capturing conversations > automating conversations<\/p>\n

\u2014 Liz Keogh<\/a><\/p>\n<\/blockquote>\n

Each feature is captured as a story<\/strong>. Stories are descriptions of requirements<\/a> and their business benefits. They use a language agreed and understood by everyone \u2014 product owner, developer and tester. It includes a set of acceptance criteria, a list of statements that must be true to declare the story “done”.<\/p>\n

\n

This will likely be an iterative process. The stakeholder will have an idea of what they want but will not know how much work will be involved. With the help of the technical and testing experts, they will understand the cost\/benefit of each scenario and make a judgement about whether they want it.<\/p>\n

\u2014 Dan North<\/a><\/p>\n<\/blockquote>\n

To describe a story we need words. If we use words from a natural language (like English) then anyone will be able to read it, but without some structure everyone’s writing style would affect the readability of the story. To avoid that, some rules were introduced and that’s how the Gherkin language<\/strong> was born, also known as the Given-When-Then syntax.<\/p>\n

\n

If you look up anything around BDD, you’re likely to find conversation, collaboration, scenarios and examples at its core, together with suggestions for how to automate them. If you look further, you’ll find Three Amigos and the Gherkin syntax and Cucumber (\u2026) and a host of other tools.<\/p>\n

\u2014 Liz Keogh<\/a><\/p>\n<\/blockquote>\n

Using this common language, it’s time to gather the team to write these stories together. The purpose is to uncover more information and refine the idea, discovering assumptions and ambiguities.<\/p>\n

\n

We involve members from testing, development, and business in an informal meeting that is more typically known as “Three amigos<\/a>” to discuss and question what we plan to build. The goal is to dispel any incorrect assumptions (\u2026) and ignorance we have around what we want to deliver.<\/p>\n

\u2014 Mark Winteringham<\/a><\/p>\n

The output of these conversations is our feature files, with scenarios that provide examples of the features, based on the information that we have uncovered throughout the collaborative conversations.<\/p>\n

\u2014 Dan Ashby<\/a><\/p>\n<\/blockquote>\n

Practice<\/h2>\n

TDD<\/h3>\n

For every method or class you need to implement, repeat the “Red-Green-Refactor” cycle:<\/p>\n

    \n
  1. Decide what code behaviour you want to implement;<\/li>\n
  2. Write a set of unit tests that assert that behaviour;<\/li>\n
  3. Run those tests \u2014 they should fail;<\/li>\n
  4. Write enough code to make them pass;<\/li>\n
  5. Run those tests \u2014 they should pass;<\/li>\n
  6. Refactor the code, and repeat steps 4-5.<\/li>\n<\/ol>\n

    These unit tests usually cover happy and sad paths (see Test types: Unit tests<\/a>).<\/p>\n

    ATDD<\/h3>\n

    For every feature or acceptance criteria, repeat this cycle:<\/p>\n

      \n
    1. Write a list of acceptance criteria to consider a feature done;<\/li>\n
    2. Automate those criteria into acceptance tests;<\/li>\n
    3. Run those tests \u2014 they should fail;<\/li>\n
    4. Decide what code changes are necessary to pass those tests;\n