Tres BienImage by Lucasbosch on Wikimedia Commons
As a programming student who has been considering a career in Quality Assurance, I need to be more familiar with the types of testing techniques my future employer may use. So I have decided to investigate three of the testing style categories I have heard about.
Acceptance Test-Driven Development (ATDD)
Acceptance Test-Driven Development is a practice where tests are written before the code. These tests are written collaboratively by team members with different roles in order to design the ideal behavior of the program from a User perspective. ATDD is used by Agile teams and involves the software developers, QA testers, and business stakeholders who collaborate closely to define acceptance criteria with a heavy focus on functional behavior.
Defining the tests this way upfront with great detail ensures the product meets user needs, encourages communication between coworkers, and requires that requirements are clearly defined. It can be time-consuming to write and maintain tests since it requires continuous collaboration, but it is worth the effort.
Tests usually follow this format: Setup > Trigger > Verification
An example test (because I must always include rabbits) is:
Given a Bunny that is available for Adoption
And a User who is confirmed as an acceptable Adopter
When User adopts the Bunny
Then Bunny’s status is marked as Adopted
—--
Behavior-Driven Development (BDD)
Behavior-Driven Development (BDD) extends both Acceptance Test Driven Development and Test-Driven Development. It emphasizes collaboration by using a common language to describe the application's behavior according to business requirements. The “Five Whys” principle is applied to each User story to tie its purpose to business outcomes. Then only behavior that will contribute to reaching those desired business outcomes is implemented.
Tests are defined in a single notation in order to make them understandable to all those who need to interact with that information.
Dan North developed BDD in 2003 to address communication issues in TDD, in an effort to make it easier for non-technical stakeholders to understand and contribute. However, it has been shown that “BDD requires familiarity with a greater range of concepts than TDD”. Agile Alliance
User stories usually follow the structure of: Title > Narrative > Acceptance Criteria
Here is another rabbit-themed example case:
Feature: Bunny Adoption
Scenario 1: Successful Bunny Adoption
Given a Bunny that is available for Adoption
And a User who is confirmed as an acceptable Adopter
When User adopts the Bunny
Then Bunny’s status is marked as Adopted
And a confirmation email is sent to the User
Scenario 2: Attempt to Adopt an Already Adopted Bunny
Given a Bunny that is already Adopted
And a User who is confirmed as an acceptable Adopter
When the User tries to adopt the Bunny
Then the system displays a message indicating the Bunny is not available for Adoption
Then Bunny’s status is left unchanged
And no email is sent to the User
—--
Test-Driven Development (TDD)
Test-Driven Development (TDD) is a software development approach where tests are written before the code. The process involves writing a test that describes one aspect of the program, writing only enough code to pass the test, and then refactoring the code to fully match the actual criteria.
TDD is used by developers to create high-quality software with few defects and easy maintenance. It is said to encourage better design, architecture, and enables easier refactoring. It can also be time-consuming, especially for complex features. There is also the risk of forgetting to rerun tests as you continue to ensure new code isn’t negatively impacting old code. There is also the danger of getting too wrapped up in test writing where you make too many at once then find out you won't even need them. Or make them too detailed so that you have to refactor them.
But with enough time and practice, you can create good habits and use this technique at its full potential.
So a User story involving TDD would jump around a lot, like a rabbit.
Here’s a short example of the possible process:
Story-
- As a new Bunny owner, I want to schedule a vet visit
- Write a test
Given a Bunny owner is not registered in the system
When the owner schedules a checkup for their pet
Owner must register as a new client
Then the checkup is added to the pet's record
- Write the bare minimum code to pass the test
- Run the test
- Refactor the code to cover more than the bare minimum
- Start from Step 1 to cover another possible scenario
- Repeat until program is complete
—--
