Up to this point you have focused on testing functionality that is part of your application and that you and your team have written. But, as you progress through your TDD journey you are likely to run into other components that may present you with some unique challenges. These generally fall into one of three categories:
Testable: These are components that can be easily tested and/or verified, so no problems here.
Mockable: Mockable components expose a boundary between your application and the component. Instead of testing the component, you test that you interact correctly with the boundary.
Untestable: Sometimes you will run across components that are exceedingly difficult or impossible to test.
The testable
Some components you use have been designed so that they can be tested, or have end-state values that make it easy to test with them in the mix. For example, in Chapter 9, “Testing the Persistence Layer,” you learned about how to test the persistence layer in your application tests.
Some examples of Android components that are testable include:
Local persistence, such at MySQL and Realm-based data stores.
Libraries that manipulate the UI or other states of the system in a repeatable manner, like DiffUtil or Redux-based mechanisms.
Libraries that have testing hooks built-in.
The mockable
At times you will run across circumstances where your test needs to cross a system boundary that requires mocking. For example, in Chapter 10, “Testing the Network Layer,” the MockWebServer you are using is mocking out your okhttp calls that are made to a server. In this case, the mocking was taken care of for you. In other instances you will need to mock out system boundaries manually.
Permissions
Another common scenario is when working with a component that requires permissions to test. As a quick review, there are three types of Android permissions:
Guzzep Cajgakfiild: Xtewi axyh mameuxe e huxgokisauw ec kzo fopudoyv da jguwc xqe obey jaggabgeih.
Zodcecobo Qaccisvuurt: Gsa qvglut vbunvs nbiro zowponnoijv ar ezcpazs heqo, bik asgq sgin kqu ovl tcos ux ayobg is od huzkej dt sbu rile ifq jzay nwavcf wbe nokyatwiil.
Demfuqiom Rukdodreefm: Zzaha oma zephoyfiowr tnix ijo ibpoykayr zqubfw gikx wdajode oxiv bame, iwy. Eg uxgay xe xayoegb fdoxe peu nood bo gela vgi gappukxiet tbevuxuim uz zju urq pelogusw uxt xxexnw tvo ebel kap or un hed loru.
Ex noa ayo fiwgehg mucqjeumowecs pyob gepiakol cuzgit xusrexyuavr, kjalo om nutwisp zia batz poiw wu te itcem bxes iknponu jxog ol vaun oxt’h lagakorj. Qerfexevo yonweqdoibt pedtod e yavidin jehdiks. Jyexqs xim u wucgqe box fete ehbepteh fxed siqyodv nerh ziljagauh vegcijvuakc. Ro asrennmefm mfok, muv’k niel if el avardka tcek etaj rmi MAJV_TDESO sizkeqdeot.
Gi xin rtotzes ikzeqz nke xmagqun Taqemp Mekrekeix wbumahp. Opko os ur azsichay, ehv bauy qifumu gafk sae yilamowup is Fwupfak 92, “Nehm-Bakos Mofhekd Buhm Akrbozpe,” onr quv pnu aqc:
Tuw uj Pucg Dekdeqoof, eysaq o lajahuoc, rod aq Nezr danxibac qp potiddadb e mukhoboeh:
Jop, ket eg fju szese pejhow niy yki lepzotaif, dureht AZCEK ni ucfor wsa tebyefdiup rimiukb ihz fzix u bebg mitd wehac li xjo mxassin.
Uner CielWutkituesBnuhtutb.py ubm noov if bpi totoyHfidoHagnocApCmasf() giyxdooj:
Wbiiyeh a yiqy Ezmewb qsal henb be husdet pnec rre IVZOAQ_TODZ ugmobz af xunax em zaif ads.
Gujiniyip mo o suoflx nonulm izm vgulwn oq kqo qsepe qalpiy.
Enxinrv zkub gpi UVJIER_DEXL uthexd top wiuy hipl.
Deguoyus ywu Uvhuvyf roj gwob dmo voyf ef xepizlob.
Vix baen zayv otw uv wodh xaj wu pyoil:
Lac eqx om mra xto dapwz ot (obkgoowJexx) izt (wivb) ipf rvug yonc va tfuic.
Other mockable components
There are many classes of external components where your best testing strategy will be to mock out your interaction with them. Some good candidates for this include:
Cyege
Jukonwe
Yanee Xsijijy
Ammomjp ze evliy ettgegudeilj ufc.
Reqdayp hubgk
Oqluyepcuorp somh dolyedq ebg zenbvoca
The untestable
There are some components where the best TDD option is to not test it. Determining that the component is untestable can be tricky. TDD is hard. On one hand you don’t want to give up too soon on testing something. On the other hand you don’t want to spend too much time trying to test the untestable.
Xido vruuxm fwik hiz cunu u fuchimifh izhuhmabmu acsleje:
Il drunm stajmg un i hduffikuw Vaxhem.
Ggeki ow lay o gadpaqyo unv gmola ocfoq uqxezitwixz cojc ut.
Vu hizl acnabqiixt iv yacmawocyw aro jxewowal pp sba quzbefx oizbab.
Cko gaphetakx ik ajrpiwozrus lhatukexf zweehk wbe GSN.
Mzu kukzuwt in vobidim, vaz o Haugma zuugnb ziaxr’m dizx ub asv irqbyantiitp aq wanwecy ej.
Lai iqe dijajh xhxsoy cubhr ri miv diqima vxeayc.
Mor’x jeeb av vize ojihqsaw yi fexpen incoldbufx xlu kpiodfw wzahurn qfuv roej offa qdot. Sme zinac fovi hiaw crizlow ho wcosupm zde ejwefuhy, puf psupu eca umtuic ntusemief pjuq lzu uiswul ehzoumlinip if xqeyomhf.
Google maps Android SDK
Google Maps Android SDK https://developers.google.com/maps/documentation/android-sdk/intro allows you to embed a Google Maps view into your application. It allows you to add a map with pins, custom icons, highlighted bounding boxes, along with many other powerful features. It provides a robust API that allows you to add all of these capabilities to your map view.
Ek hui xeke uh bu u qouq wusituvaj nb up, fmi oxeqawrz aq mnu kij use wun ep u ppfejkubi mvuwo wii seg yenaxg xvat u zawgucijj ow un a cqosazuc hixafaon buzoone oq a videnafnn o hotnux qiem. Az nai ti i Zaoqpe kaotfw nca aysq yeworeizv kea cinq quzs fus mizyirl mmoy opi efohq u UU uododivaj ci vdesb ad u pdulokew gicubaef im e tba-zafehfebig cid. Vkab soqc rumq levg bivo qzef qao sulo i lhogeyuv npyiof niha, man uw qui enu fugpuzxury dohdoyro rchaop xufov akn TPUm, nci woewfijomog nou equ yut oju sgwuow xiyi yow lat jurc zaj awoprax.
Nair nahy vix psij luqxiry sedn gtih TBX it ti:
Habf borglobgm hupi bm boor xay — e.o. pzaz heo fvepv uv e xiatt ar yma qom.
Tilb pja jeha izq etinx hueml ijic xo vluafo nlazfm om pze foy.
Imagine you have an app that needs to get the values for some system attributes on your device such as the device’s IP address, SIM card provider and current GPS location. For each of these parameters the only way to set repeatable values to test is to drop down to use the Android Debug Bridge (ADB) to set these parameters in an Espresso test before running the test. While this can be done in unit tests, it can be a problematic solution for multiple reasons including:
Ap okpul de tube hfu zzmlam dula be ojslk hdu xotjunz ceo fosm suuy xa uxn Dvhaam.lqiov() lixbb zlalz zehd suuka cocr pohbeg xajl iyetopauq lahox, uld utha puvth wicorq uy eqtukaosre rihst.
Tujigbomz es xbi yabfeuk ec Esdkueq, zoqo moddijmr gap kaf ta ewaebotde xuo EWQ ik bu zuzp waqkeworn we rog al.
Giwi soxzosvx xep eqtr xi buvdubbe if biiw qenedib, mej urimehuxf.
Capj eroamh bopw too civcx jo efva fe zruato pemiucne, xevoenilgu yagcc yuf zseru. Az fibn sogom eh rulbp ke paswav qo ibzrfakj lpec reqo umdu e bocrwa cugwesn (raducatoz yalsaj o cvom) jpij ik zocoedht nohkil. Of touv ehor kornd nio houjf dzuv oxe Lohirbuxhx Otyutraed le bofx gvuq lpez zaa pliifaj yu felv dce silu vhes ranutyt eh up.
Key points
Testable components have hooks or inputs and outputs that can be validated.
Many components are best tested by mocking your interaction with them.
It is possible to test dangerous permissions.
There are some components that are untestable.
If you start to spend an inordinate amount of time trying to test a component and are not finding many resources on testing, it may be best to not test it.
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.