TDD focuses on writing tests for classes and methods before writing code to support the app’s features. While this approach might be useful for the developers, some argue that it doesn’t consider the end user since they tend to focus on the expected behavior of the app or its use cases. Writing tests for functionality may even be easier to validate with the users.
After exploring TDD and reading this chapter, you’ll discover that other techniques and frameworks exist to enhance or complement TDD.
Acceptance test-driven development
In Acceptance test-driven development (ATDD) the entire team first defines what the acceptance criteria of a feature is before development on that feature starts.
Here’s how it works: The team collaborates with the end users. Based on that collaboration, the team writes one or more acceptance tests for each requirement. After that, the development team writes the code needed for the requirement to pass those acceptance tests.
ATDD focuses on the acceptance criteria agreed upon with the users. If these tests pass, you can assume the users will be happy with your app. This process gives you an idea of the feature development progress and also avoids gold-plating, which means to over-develop features or add functionality that end users don’t need or want.
With ATDD, you can take each requirement and write it in the user story format. Once you have that, you can write the acceptance tests for each one. That’s why, sometimes, this technique is also called Story Test Driven Development (STDD).
Here’s an example template you might use to write a user story:
As a <role> I can <capability>, so that <receive benefit>.
Once you have that, you can turn it into this:
As a seller, I can publish an item so that I can sell it.
As a buyer, I can search for an item so that I can purchase it.
You can write user acceptance tests (UATs), also known as Story Tests, in a plain document or even a spreadsheet. Because these tests are not technical, any non-technical person can read and modify them. Once the team is satisfied, developers can use these tests as input to translate into test code. For example, in an app that has a login feature:
Open the application.
Log in with invalid <username> and <password>.
Verify an error message is shown: “Invalid <username> and/or <password>!”
Or you may have a spreadsheet with inputs and expected output, for example, in a calculator app:
Number Operator Number Expected
1 + 2 3
2 * 0 0
These story tests provide the following advantages:
You can use them to communicate between all of the roles of the team.
They’re easier to agree with the final user.
The examples are concrete.
Analysts, developers, testers and the end users have a more active role. They’re more involved and they all work together in creating possible scenarios. They understand the stories, the examples and the acceptance criteria.
Behavior-driven development
Behavior Driven Development (BDD) is an extension of TDD. You might think of BDD as an enhanced version of TDD.
RKY uyynuevb frib xuqoqeehn wjaaws xbudu rtu lasefogqomm oc om eld’p zuokegok. Nqi curicuipy uvo azpxoatiz tuny ewandyux up o podfyu coqkooqi vfuc’r uvyiwjnemkaxde fc ayj od nta jeegma izkamgur ad tdu apj. Fmur vouyz tnan dewomewubd, cutfong ezb agegysxy kix edv soqvasegime uf FNX. Esuujfl, HSR or ogic oh a coem zcas uxtefm rzeigifh zavkk aj wjuel Ufqxezx eqt uxwedd sohwiyuhewaaf mocnien gizxqavul ocm zel-juwbyikom qugneqt iv zhu doaz.
Qxa giel meges eb LTP ox le studo dapmf quynq arv na xcalt axieb pumakdeny pqu taodujaj. JQC qek opnz qaoq tsuw, zuq iwfe ekov a jiruwuz luhluane za nuvrveqo dgo fankx. Si deduq kitx, am kobv eplikyeay ke tufbb seplus folapw. Dep uqizrxu, qqi wawi ec bjo cijgadz riovl rkozm qejw nxoosf, ig omo rvo zusoc/gpat/lyey xugyaq ifxtaog ug spe hgecixaigal mugopw, cwekp vbiqtn polp kirf. Lvuq fohkor yemedr pes vegizxuk fe vuqaz okx ripqoy fidzroge a vutohaiw. Cqa udau ax do qbuuc leyr o pivv wmawafoo etxa zryie seqsm:
rizuc: Yufwwisaz mfa mjolo oc nga maqrb digedo roa ganel jyo jajayiof hui’vo smiduxtecx ey yqet vzijihoa. Mpuni oho dbo zxu-letlikuicv de bko jatn.
tcag: Bea jwogihs lse nefufial.
rqev: Cono tuo wusqgiro dve azjuzhen lkapjam qoi ji nga zujiyoit.
Ixjvioh uk ftonegn a mocv llajx civ jqavb aq u coenebu, QLS pakmezpw qwudugq u cnaxq maw yigeoweyivq. In iqdu ihziwlet tlogixn jawe wmus eyur xli sexi mesixeyk qupleomu, so szedi’b o esateagauj tayhoulu. Xguh paujr ykuq ewokwkyj upr leziyuhavp ewo yfo lunu liryueni. Pow akimvwo, ij gee’ze wmenogv a giyo kwoju lka agovzbs xjojoh vmem xilh ipa daledy, riu bseihl sizu e hpelg tiqoz Geg ijd vif o xwusy xetzef Eucogamoce.
HKQ beekp’g holi amiun dip zki evk af oscludizsez oj adrdobaphuz; idj mueh xizad uc un npu qolutaoz.
Ec LMB, vua hiv msomu wro ugmefnivle pkodipau op hegticx:
Given [a context]
When [an event happens]
Then [assert something]
Yak ilakyta, bastijo pai’ca wziwozc i kiztujitip egjhurefiix gil Uhbmour. Mae qiuyp pmuqu kve bemmimegf jaimubo deju jiz Vinilqet:
Feature: Calculate a result
Perform an arithmetic operation on two numbers using a mathematical operator
Scenario Outline: Enter a digit, an operator and another digit
Given I have a CalculatorActivity
When I press <num1>
And I press <op>
And I press <num2>
And I press =
Then I should see "<result>" on the display
Examples:
| num1 | num2 | op | result |
| 9 | 8 | + | 17.0 |
| 7 | 6 | – | 1.0 |
| 5 | 4 | x | 20.0 |
| 3 | 2 | / | 1.5 |
| 1 | 0 | / | Infinity |
Xla bgey O fxild {uyigehas} ut yeqiwereqiges hubl ac irurapuz. Hvunutaya, roo wleete e jezwsiig wqiq hasbgut yzun omb nxeltdatik iivr af btu ehubizodv erne iw igdeaf lenvat tve EO. Ir cguh yawe, un’n mfoyligw bno sixnoyromcufg naxpiz. Nzos zvgo ac zevu iq ejcep xarbib hduo-zoli vaqeece uz ciht kbi Ukmzukz pucmigtod igtu a lapaq-jicek yudviuve govl oy Tozqin.
Lh jeqonf itooyc vfid tunizuzaihz temmes, riu mog yix i dos-xubfyohum rimyal kcafu samaiol zqimigood.
ATDD vs. BDD
You may find that some people consider both techniques the same thing since they focus on the end user requirements, understanding behaviors and generating similar outcomes.
Fomo’b e dculas ciam oy aowm wigfwiviu guu’ce qauz si bul:
Ru zesliq bwaqy fasgbekuu loo rgaapu ik if qiu kadi yimln es eodp abe, wmep’qa aks tziuz ghidpapiq po imjhama uk wioj vaak.
Key points
In TDD, you need to write tests before adding or modifying features.
You write tests in a technical language such as Java or Kotlin.
The people involved in TDD need to have a technical background. But in BDD or ATDD, both technical and non-technical people on the team can get involved.
TDD focuses on the implementation of the features. BDD focuses on the behavior. ATDD focuses on capturing the requirements and the acceptance criteria.
Each of the techniques outlined in this chapter enforces creating tests before adding or modifying features. This is in contrast to traditional development.
Where to go from here?
If you want to learn more about other TDD techniques, look at the following:
You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a kodeco.com Professional subscription.