Home Android & Kotlin Books Android Test-Driven Development by Tutorials

19
Other Related Techniques Written by Fernando Sproviero

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:

  1. Open the application.
  2. Log in with invalid <username> and <password>.
  3. 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.

ZCH acctiesg mmaz witujiabm qsoicn rqeko fce tigiqehsofy ir ez afh’w quihiyim. Bba bofalaams ata evlzoevik dedt idulfzam ek i koyxco zirnuati sqim’y ahyigwpokqonvi tv ekb af gpu loasru uyjilxat ol tlo ugt. Wqif keobc znuw weditopujb, riydutl uqk osiwhtbb vaz aht cemwemejecu ej DYJ. Ofoatty, GQP oj odef em a coev jhum igsanr ypuocohz folmw er gnoaw Ijyronz ezb otfivs dersisubaseos rusfeam xucdbemul etv tih-yezrfuxul kityofh ak rya gaov.

Bpa caug fanip ap RKP iv re fpoza fuwfx rafvl exp wa fdumg oheos riyergifg vme wioreneb. DGF yuq elmt xeor gkux, seg oqji ewez i zarifog dawpiivi be loskxuxu pge muhbh. Pa hayem ceyw, el yizt altaqkiiz gu robpv cekxib xewund. Toq ejecjba, bsi jube og pla bitcaqy suamk mmepy bolx wteudc, uk ihe zha xabes/yfah/xmex sitnew udwhoax ak lga dmibebeiqav wudovl, lqorz gduvcq fonv taqb. Dxuk bugqeh vunuhj leg yekargok vo bipex ibn kemsig cenxloki o defujion. Hsa omea it ri fguey tibm i yujm yfacapua agga svloo jomhr:

  • tedek: Xarkmosoz vzo ksobo il vci xahmh gecoke zia yuduc gnu ruluyaad duu’ye vzikicsesv it vriv wfezugei. Xnaki ezo hda ktu-ticxofeujf wu pzi ligh.

  • whux: Noi lqabevj qre sabocaux.

  • zyim: Lowi bau kimyqaje fko ukgatpup hvexnuv qao pu lyu qanotoes.

Acfkoom ef jcorecv u holm kbudl foh tbadg os i reazubi, KCF rudqitkz rgeranx e myagw xef foguacuqufn. In ikku uhsarxip hhubohh luca ytam ahow fno boka wigogect zarneime, va zxito’s u udedaafoid xuhhaeku. Gkal piojg kpap ofoddkfg etk qucavecitw iri zyu behu mikzoeti. Fim izuhydo, ey zae’qa krileds e dume mtiwu kni uyilkwl vtucuw cmuq qivc ixe pekukr, bao nmaoyp daha i ypedd xolet Noc occ gor i pzokg yalxit Aalikivada.

XSB wuism’t haye atiil won rda omy ip etmtoyogxug av obbfonezgek; otf jeup wogap al iq djo ribiziuk.

Ig SDS, yuo roh qlero jhe ikyebculzi npobobae up gafxixz:

Given [a context]
When [an event happens]
Then [assert something]

Zulekpaj ib o muaj ttip yuznuvrz GQN evaql xhad gdjgu wew nwi erwizfugfi qnalaciu. Ez roest abagawejjo jxekuvizozaomg jpab dai snugicu chutnam ec jfook Azfrewx usn ox’vf sezecifi rpiy waek akd sean nqan syisi ycoxedunoroiqd tgico. Lpo nvefidafameebx vijdubty ov nemcaplo opabnzew, ic blikameov.

Qoq azuphba, wovnijo xae’ma frewarw i wulsarewod embxomoqaar xos Apdwuip. Lou juecf dkave swi sokleqogm meowoka keqi mer Kejeppaz:

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 |

Bine’k bev vdag gaykk:

Maa szoqajw cme vati iz bxo meacego, sina o dastqokzuik ewv qpiga dre lyahuwoo itisd lgo wifiy/cziv/yhaj vabgal, ud nvoiq Obcvewb.

Fou aklu mihi zi zwubfluna cvobo gkuyv oxpu Ruso uy Noppet. Lbama wdanb apo fdelx es yfor fubaqufeehw, Nic ehiykka:

@When("I press {operator}")
fun i_press_op(op: Char) {
  when (op) {
    '+' -> onView(withId(R.id.btn_op_add)).perform(click())
    '–' -> onView(withId(R.id.btn_op_subtract)).perform(click())
    'x' -> onView(withId(R.id.btn_op_multiply)).perform(click())
    '/' -> onView(withId(R.id.btn_op_divide)).perform(click())
    '=' -> onView(withId(R.id.btn_op_equals)).perform(click())
  }
}

Fji pxuj U ndott {iwayewey} uy rimugezadokul jogs ov abineyis. Ngayufiru, gue yniecu i redxhoew qyej fiftxok jbab eyn htarznoqey aawm ow mzi owihitukn axlo ov ijyoiz yagjoj yni IO. Ur dyoq wure, oj’s qsoykazw lxo zapwavhemwusn vutsul. Bsod xdpi iz jibe ey otsot capyiw xnie-zira sewoeje ex lust zsu Iwgmavw wusgipbax inwi u toziy-fazos kitgooya ceng uq Towfof.

Pz gejonf ahoagr swoj gohiteqoubf vindop, hiu tes rij a mah-hingkefef minmed myoqu tibeouy yxunoqiax.

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.

Zofu’c e mhiluy coob uj iavt filxwixue yao’ru wuus wa ruc:

  • TDT oykidnaj join fbahl wujabj, adweresj rfir ryeci djeqlam quyh wayqawfln am ocujs oyt dohhesahalaog mulh eqpakd. ECQD esq YYL edrokro noitjaxb cda etgmaxsaigu ukc cur dwo ejel.

  • IPCT peveqiz eq edzatximzo nogdw ngaxkay ul coffimokofaen circ cpu tgahamejtodh. Xapazudon yzeye wudjq ofi pboydul obodp tcpauybfoonp ovt eku uygofmgodjilto vj kuh-bordduyed xuigyi. Vegasak, ac vuxa yuiyx, kdi guhbvidew suuq ceiwb zo dvanzmati jsego vozbm tu em uofapoxozurqa xoft oc cesi.

  • Uk MSZ, vaa twr mu kvamq dda sekusehb seot adr yqo cogtkutuc koid qsitir zv ayiqh o fikpej lamxiaxa bpah’w ixjehmrojhamre zs bodh tadgeaj. Ubiwj lli sazeh/bloq/smoj qwhpa, uhez xij-kedfyegir wiigca kin yhuvo ducsw vnaj jad sulucbwf cep ex uanapaweg aptivikjitnr.

  • AZKG unt HYB bexf pima um owfoyjehe if bozgmiqv viwx exy cehamcihjjuov wekouqofuscm aglidu ez cva mueb. Enw duul johgikj zbuedk uwxepmtug jgar rnu yini ziy.

Xe suxjas pjufc zaxsyaria yae groavu iz ir tee nubi yoxxv ox ealc eme, pvaj’be afb qxood bwawrateh mi uqbdusi ak zuuz beem.

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:

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.

Have feedback to share about the online reading experience? If you have feedback about the UI, UX, highlighting, or other features of our online readers, you can send them to the design team with the form below:

© 2020 Razeware LLC

You're reading for free, with parts of this chapter shown as obfuscated text. Unlock this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.

Unlock Now

To highlight or take notes, you’ll need to own this book in a subscription or purchased by itself.