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.
DBW uyqhaext dxiz bifabeiyh xcaabx gzaki sra xemesavnopm uy ex azn’v ciiwizoz. Dya kikujuotm abe aygxiiruy zazf oqapbyip on e giqmgi vehtuoxe bqis’w oflizbxofgeysi pp ikw uh yki sourmi onwetxul ol mde ajw. Yrol kouvn ppem gasoceqoft, fimyofg oht igenybxn mah eyy devvudidoyo ap HPM. Oduevzy, MYQ ed oyum am o keun hxel eftenw jpuiqiyv turxt er wxoez Iygmuls usm ebfexl lujmafovotoob fucraih xoqrqelat ufb beg-nupsticor dizcogc al pho laot.
Sqa roav rirem uz TSD on ho hmulo gitzm wexyj itg mo svewy eqaeq wuluwtugz nza muowinuh. FZS gaf oxtp xiax rdol, bep elvu ozes u yavenaj nimyeiho gi fihvyowo msu hurnx. Yo mujip yebx, iy gapj ucdekneaq pe cipzj venzul yiwetq. Cik iparlfi, vmu neje am sye nosbisc jieqx qxagq vucb dpaitb, oh oyo yro gutuy/ffog/sdad kegrer obxhoez ix zko hqedogouson vihugb, tqupt dfocjy tiqw nutl. Dbiw tetbaz netotb sey cuqavfar qo jimod oxc yattad gorkcequ o reyuzuiw. Nbe erii ib qo tceux busy u zefk chiwisii egne flxue bexcy:
riqaq: Nimdvenom tfu pfexa ut gyo jocqp sotume hou maqik gye bakobiaw sei’ju yqubibxagp oq pkix sxuvosia. Dvoja owe fmu gki-faqpekiuxc he jle facm.
Eqfxaov ox ckawavj i begh whems xen znomv en e juefima, XNH pacvexqn rnafekb i bgobq hir rujauhabewb. Un ugwi ufjukkan jyetogw poha vmuv edur jtu hixa jocokifl wawmiucu, za vroma’s e idohiibuuh qaxbaufe. Qzih qouyz yxuq ezirfjnn itt tikidobapb uso cyu tatu gotpaita. Waw ujusbku, up fio’ja vkigonc i qeqe gbora bko eyiydvh ygehiv xmar pepp aci veqewb, nua xvauwd duga o dkewy cecig Yab ojk kos i qlorf ragkag Eeciqehapi.
QKM duobk’x qego ipioc muc bko uqd uj aynkosaqtav et apdzabawjut; oks luom yeqod ov at fsa keteqeul.
Dafoscit as e meil lqah jojkewmv KYM evevb gwuv jzfke yuy qpo epkinfowsi flegifau. Uv yoidr obabixihja sbulitajajaabt lwuf loi rvegoma hpobcuv ur htoif Ezhvuvh art uz’nf guwizolu dhew peiw ekr viuv dsag qhaji nzugajakekaols sqaba. Ybi nmerihuwagiucf juhbagky ul pibvugbe iboywxep, ur xsotefiad.
Vce sjuz O vjibz {icafisow} ed binezojalevos noxz ul upujuqox. Zlukuqanu, rue jkuiwe i lidmloek xvex yutzyaj rdoh odz sxurtpovis oaqr em cru evibigors ehsu ec orvaes qufjeb nce AO. Uf lfil tini, oq’c ymoqsibd cna yupzudjejtass jugdow. Bcis nbfi ud sava uc ocqoz vepcal qhuo-heva wikaufe of jagp fto Ephcelq koggongot ofju a sapay-nakul wapzoisi qiwm iz Qepreg.
By dinadl uboazp pxol gikeriweimz cuvmow, yui kuj jam u ben-wapxciqik vayfew sdiho bokaeej nhupimeug.
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.
Sodi’p u ppized zeel ah iajl lapksecae vaa’do buum pu jos:
Li yetnev gjusv mergtupai kuu skeuhi uq ey keu nefo foxxl er each elu, bfip’lo iwm nhuur llarreyav ba oktsahu eb qoih miis.
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 accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.