Apa TDD lan unit testing [terjemahan]

Artikel iki minangka adaptasi saka bab saka buku The Complete Software Career Guide. Penulis, John Sonmez, nyerat lan ngirim sawetara bab ing situs web.

Glosarium singkat kanggo pamula

Pengujian unit utawa pangujian unit minangka proses ing program sing ngidini sampeyan mriksa modul individu saka kode sumber program kanggo bener. Ide iki kanggo nulis tes kanggo saben fungsi utawa metode sing ora pati penting. Pengujian regresi minangka jeneng umum kanggo kabeh jinis pangujian piranti lunak kanggo ndeteksi kesalahan ing wilayah kode sumber sing wis diuji. Kesalahan kasebut - nalika, sawise nggawe owah-owahan ing program, soko sing kudu terus bisa mandheg kerja - diarani kesalahan regresi. Asil abang, gagal - gagal tes. Bedane antarane asil sing dikarepake lan sing nyata. Asil ijo, lulus - asil tes positif. Asil nyata ora beda karo sing dipikolehi. *** Aku duwe hubungan banget campuran karo Test Driven Development (TDD) lan testing unit, dadi saka katresnan kanggo sengit lan bali maneh. Aku penggemar banget lan ing wektu sing padha mamang curiga babagan panggunaan iki, lan liyane, "praktik paling apik." Alesan kanggo sikapku adhedhasar kasunyatan manawa ana masalah serius sing muncul ing proses pangembangan piranti lunak: pangembang, lan kadhangkala manajer, nggunakake alat lan metodologi tartamtu mung amarga padha dadi "praktik paling apik". Alesan nyata kanggo nggunakake tetep ora jelas. Sawijining dina aku miwiti nggarap proyek tartamtu, lan ing proses kasebut, aku dilaporake yen kita bakal ngowahi kode sing disedhiyakake dening akeh tes unit. Ora guyon, ana kira-kira 3000. Iki biasane minangka tandha apik, sinyal yen pangembang nggunakake metodologi lanjut. Kode karo pendekatan iki paling asring kabentuk, lan adhedhasar arsitektur uga-dipikir-metu. Ing tembung, ana tes nggawe aku seneng, yen mung amarga tegese nggawe tugas minangka mentor programer luwih gampang. Amarga kita wis duwe tes unit, aku mung kudu nyambungake tim pangembangan kanggo ndhukung lan miwiti nulis kode dhewe. Aku mbukak IDE (lingkungan pangembangan terintegrasi) lan mbukak proyek kasebut. Iku proyek gedhe! Aku nemokake folder kanthi label "tes unit". "Great," pikirku. - Ayo miwiti lan ndeleng apa sing kedadeyan. Mung sawetara menit, lan kaget, kabeh tes lulus, kabeh dadi ijo ( "ijo" minangka asil positif saka tes kasebut. Sinyal yen kode kasebut bisa digunakake kaya sing dikarepake. Abang nuduhake "gagal" utawa gagal, banjur ana kasus nalika kode ora bisa digunakake kanthi bener - cathetan penerjemah ). Kabeh padha lulus tes. Ing wayahe, skeptis ing kula tangi. Kepiye carane, telung ewu unit tes, lan padha njupuk kabeh bebarengan - lan menehi asil positif? Ing laku dawa, Aku ora bisa ngelingi wektu nalika miwiti nggarap proyek tanpa test unit negatif siji ing kode. Apa sing kudu ditindakake? Priksa kanthi manual! ChY milih salah siji test acak, ora paling mbukak, nanging langsung cetha apa kang mriksa. Nanging nalika nggarap, aku weruh ana sing ora masuk akal: tes kasebut ora ana perbandingan karo asil sing dikarepake (negesake)! Sing, ing kasunyatan, ora ana sing dicenthang ! Ana langkah-langkah tartamtu ing tes kasebut, ditindakake, nanging ing pungkasan tes, ing ngendi dheweke kudu mbandhingake asil sing nyata lan samesthine, ora ana priksa. "Tes" ora nyoba apa-apa. Aku mbukak test liyane. Luwih apik: operator perbandingan karo asil wis dikomentari. Apik banget! Iki minangka cara sing apik kanggo nindakake test pass, mung menehi komentar kode sing nyebabake gagal. Aku mriksa test liyane, banjur liyane ... Ora ana sing mriksa apa-apa. Tes telung ewu, lan kabeh mau ora ana gunane. Ana prabédan ageng antarane nulis tes unit lan pangerten testing unit lan pembangunan test-driven (TDD).

Apa tes unit?

Ide dhasar saka tes unit yaiku nulis tes sing nguji "unit" kode sing paling cilik. Tes unit biasane ditulis nganggo basa pamrograman sing padha karo kode sumber aplikasi. Padha digawe langsung kanggo nyoba kode iki. Tegese, tes unit minangka kode sing mriksa kabeneran kode liyane. Aku nggunakake tembung "test" cukup liberally ing konteks, amarga tes unit ing sawetara pangertèn ora tes. Dheweke ora ngalami apa-apa. Maksudku yaiku nalika sampeyan mbukak tes unit, sampeyan ora nemokake manawa sawetara kode ora bisa digunakake. Sampeyan nemokake iki nalika nulis tes, amarga sampeyan bakal ngganti kode nganti tes dadi ijo. Ya, kode bisa diganti mengko banjur tes sampeyan bisa gagal. Dadi ing pangertèn iki, tes unit minangka tes regresi. Tes unit ora kaya tes normal ing ngendi sampeyan duwe sawetara langkah sing bakal sampeyan tindakake lan sampeyan bisa ndeleng manawa piranti lunak kasebut bisa digunakake kanthi bener utawa ora. Sajrone proses nulis tes unit, sampeyan nemokake manawa kode kasebut nindakake apa sing kudu ditindakake utawa ora, lan sampeyan bakal ngganti kode kasebut nganti tes kasebut lulus. Napa ora nulis tes unit lan priksa manawa lulus? Yen sampeyan mikir babagan iki, banjur tes unit dadi sawetara syarat mutlak kanggo modul kode tartamtu ing tingkat sing sithik. Sampeyan bisa mikir tes unit minangka spesifikasi mutlak . Tes unit nemtokake manawa ing kahanan kasebut, kanthi set input tartamtu iki, ana output sing kudu sampeyan entuk saka unit kode iki. Pengujian unit sejatine ngenali unit kode koheren sing paling cilik, sing ing pirang-pirang basa pemrograman - paling ora berorientasi obyek - minangka kelas.

Apa sing kadhangkala diarani unit testing?

Pengujian unit asring bingung karo pengujian integrasi. Sawetara "ujian unit" nguji luwih saka siji kelas utawa nguji unit kode sing gedhe. Akeh pangembang ngaku yen nulis tes unit nalika nyatane nulis tes whitebox tingkat rendah. Aja padu karo wong-wong iki. Cukup ngerti yen dheweke bener-bener nulis tes integrasi, lan tes unit sing bener nguji unit kode sing paling cilik kanthi kapisah saka bagean liyane. Bab liya sing asring diarani tes unit yaiku tes unit tanpa mriksa nilai sing dikarepake. Ing tembung liyane, tes unit sing ora bener nguji apa-apa. Sembarang tes, unitized utawa ora, kudu kalebu sawetara jinis verifikasi - kita nyebataken mriksa asil nyata marang asil samesthine. Rekonsiliasi iki sing nemtokake tes kasebut lulus utawa gagal. Ujian sing tansah liwati ora ana gunane. Tes sing tansah gagal ora ana gunane.

Nilai Unit Testing

Napa aku dadi penggemar unit testing? Yagene mbebayani kanggo nelpon pangujian umum, sing kalebu nguji dudu blok paling cilik sing diisolasi saka kode liyane, nanging potongan kode sing luwih gedhe, "ujian unit"? Apa masalah yen sawetara tes ora mbandhingake asil sing ditampa lan samesthine? Paling ora padha nglakokake kode kasebut. Aku bakal nyoba nerangake. Ana rong alasan utama kanggo nindakake tes unit. Kapisan yaiku nambah desain kode. Elinga carane aku ngandika yen testing unit ora tenan testing? Nalika sampeyan nulis tes unit sing tepat, sampeyan kudu ngisolasi unit kode sing paling cilik. Usaha kasebut bakal nuntun sampeyan nemokake masalah ing struktur kode kasebut. Sampeyan bisa uga angel banget kanggo ngisolasi kelas tes lan ora kalebu dependensi, lan iki bisa uga nggawe sampeyan ngerti yen kode sampeyan digandhengake banget. Sampeyan bisa uga nemokake manawa fungsi inti sing sampeyan coba nyoba kalebu macem-macem modul, sing ndadekake sampeyan yakin yen kode sampeyan ora cukup koheren. Nalika njagong mudhun kanggo nulis test unit, sampeyan bisa dumadakan nemokake (lan pracaya kula, mengkono!) sing ora ngerti apa kode wis mestine apa. Patut, sampeyan ora bakal bisa kanggo nulis unit test kanggo. Lan mesthi, sampeyan bisa nemokake bug nyata ing implementasine saka kode, wiwit unit test meksa sampeyan mikir ing njaba kothak lan nyoba set beda input sing bisa uga ora dianggep. Yen sampeyan strictly netepi aturan "nyoba unit paling cilik kode ing isolasi saka liyane" nalika nggawe tes unit, sampeyan bound kanggo nemokake kabeh limo masalah karo kode lan desain modul sing. Ing siklus urip pangembangan piranti lunak, tes unit luwih minangka kegiatan evaluasi tinimbang kegiatan tes. Tujuan utama tes unit nomer loro yaiku nggawe set tes kemunduran otomatis sing bisa tumindak minangka spesifikasi prilaku piranti lunak tingkat rendah. Iki artine apa? Nalika sampeyan uleni adonan, sampeyan ora bakal pecah. Saka sudut pandang iki, tes unit minangka tes, luwih khusus tes regresi. Nanging, tujuan tes unit ora mung nggawe tes regresi. Ing laku, tes unit arang nyekel regresi, amarga owah-owahan ing unit kode sing sampeyan nyoba meh tansah ngemot owah-owahan ing test unit dhewe. Pengujian regresi luwih efektif ing tingkat sing luwih dhuwur, nalika kode kasebut dites minangka "kotak ireng", amarga ing tingkat iki struktur internal kode bisa diganti, nalika prilaku eksternal samesthine bakal tetep padha. Tes unit uga mriksa struktur internal, supaya nalika struktur kasebut diganti, tes unit ora gagal. Padha dadi ora bisa digunakake lan saiki kudu diganti, dibuwang utawa ditulis maneh. Sampeyan saiki ngerti luwih akeh babagan tujuan tes unit sing sejatine tinimbang akeh pangembang piranti lunak veteran.

Apa Pengembangan Test Driven (TDD)?

Ing proses pangembangan piranti lunak, spesifikasi sing apik yaiku bobote emas. Pendekatan TDD yaiku sadurunge nulis kode apa wae, sampeyan kudu nulis tes dhisik sing bakal dadi spesifikasi, yaiku, nemtokake apa sing kudu ditindakake kode kasebut. Iki minangka konsep pangembangan piranti lunak sing kuat banget, nanging asring disalahake. Biasane, pangembangan sing didorong tes tegese nggunakake tes unit kanggo nuntun nggawe kode aplikasi. Nanging nyatane, pendekatan iki bisa ditrapake ing level apa wae. Nanging, ing artikel iki kita bakal nganggep yen kita nggunakake tes unit kanggo aplikasi kita. Pendekatan TDD nguripake kabeh ing sirah, lan tinimbang nulis kode dhisik banjur nulis tes unit kanggo nguji kode kasebut, sampeyan nulis test unit dhisik banjur nulis kode supaya tes kasebut dadi ijo. Kanthi cara iki, unit testing "drive" pangembangan kode. Proses iki bola-bali bola-bali. Sampeyan nulis test liyane sing nemtokake fungsi luwih saka apa kode kudu nindakake. Sampeyan banjur nulis lan ngowahi kode kanggo mesthekake yen tes rampung kasil. Sawise sampeyan duwe asil ijo, sampeyan miwiti refactoring kode, yaiku, refactoring utawa ngresiki munggah kanggo nggawe luwih ringkes. Rantai proses iki asring diarani "Red-Green-Refactoring" amarga pisanan tes unit gagal (abang), banjur kode kasebut ditulis kanggo adaptasi karo tes, nggawe manawa sukses (ijo), lan pungkasane kode kasebut dioptimalake ( refactoring)..

Apa tujuan TDD?

Test-driven development (TDD), kaya unit testing, bisa digunakake kanthi ora bener. Iku gampang banget kanggo nelpon apa sing sampeyan tindakake "TDD" lan malah tindakake laku tanpa ngerti apa sampeyan nindakake iku cara. Nilai paling gedhe saka TDD yaiku tes ditindakake kanggo ngasilake spesifikasi kualitas. TDD sejatine minangka praktik nulis spesifikasi sing tepat sing bisa dipriksa kanthi otomatis sadurunge coding ditulis. Tes minangka spesifikasi sing paling apik amarga ora ngapusi. Dheweke ora bakal ngandhani sampeyan sawise rong minggu nyiksa kanthi kode "dudu sing dakkarepake." Tes, yen ditulis kanthi bener, lulus utawa gagal. Tes kanthi jelas nuduhake apa sing kudu kedadeyan ing kahanan tartamtu. Mangkono, tujuan TDD yaiku kanggo menehi pemahaman lengkap babagan apa sing kudu ditindakake sadurunge miwiti ngetrapake. Yen sampeyan miwiti nganggo TDD lan ora ngerti apa sing kudu dites, mula sampeyan kudu takon liyane. Peranan penting liyane TDD yaiku njaga lan ngoptimalake kode. Pangopènan kode larang. Aku kerep guyon sing programmer paling apik sing nulis kode paling cendhak sing solves sawetara masalah. Utawa malah siji sing mbuktekaken sing masalah iki ora perlu kanggo ditanggulangi, lan kanthi mangkono mbusak kode, awit iku programmer sing nemokake cara tengen kanggo ngurangi jumlah kasalahan lan ngurangi biaya kanggo njaga aplikasi. Kanthi nggunakake TDD, sampeyan bisa yakin manawa sampeyan ora nulis kode sing ora perlu, amarga sampeyan mung bakal nulis kode kanggo lulus tes. Ana prinsip pangembangan piranti lunak sing diarani YAGNI (sampeyan ora butuh). TDD nyegah YAGNI.

Tipikal Test Driven Development (TDD) Workflow

Ngerteni makna TDD saka sudut pandang akademis pancen angel. Dadi ayo goleki conto sesi TDD. Mbayangno njagong mudhun ing meja lan cepet sketsa metu apa sampeyan mikir bakal dadi desain tingkat dhuwur kanggo fitur sing ngidini pangguna kanggo mlebu menyang aplikasi lan ngganti tembung sandi yen lali. Sampeyan arep sing bakal miwiti karo implementasine pisanan saka fungsi login, nggawe kelas sing bakal nangani kabeh logika kanggo proses login. Sampeyan mbukak editor favorit lan nggawe test unit disebut "Login kosong ngalangi pangguna saka mlebu." Sampeyan nulis kode test unit sing pisanan nggawe conto kelas Login (sing durung digawe). Sampeyan banjur nulis kode kanggo nelpon cara ing kelas Login sing ngliwati jeneng pangguna lan sandhi kosong. Pungkasan, sampeyan nulis priksa marang asil sing dikarepake, mriksa manawa pangguna kanthi login kosong bener-bener ora mlebu. Sampeyan nyoba kanggo mbukak test, nanging ora malah ngumpulake amarga sampeyan ora duwe kelas Login. Sampeyan ndandani kahanan iki lan nggawe kelas Login bebarengan karo cara ing kelas kanggo mlebu lan liyane kanggo mriksa status pangguna kanggo ndeleng yen lagi mlebu. Nganti saiki sampeyan durung ngetrapake fungsi kelas iki lan cara sing dibutuhake. Sampeyan mbukak test ing titik iki. Saiki kompilasi, nanging langsung gagal. Saiki sampeyan bali menyang kode lan ngleksanakake fungsi kanggo pass test. Ing kasus kita, iki tegese kita kudu entuk asil: "pangguna ora mlebu." Sampeyan nglakoni tes maneh lan saiki wis lulus. Ayo pindhah menyang tes sabanjure. Saiki ayo bayangake sampeyan kudu nulis tes sing diarani "Panganggo mlebu yen ngetik jeneng pangguna lan sandhi sing bener." Sampeyan nulis test unit sing instantiates kelas Login lan nyoba kanggo mlebu nganggo jeneng pangguna lan sandhi. Ing test unit, sampeyan nulis statement sing kelas Login kudu njawab ya kanggo pitakonan apa pangguna wis mlebu. Sampeyan nglakokake tes anyar iki lan mesthi gagal amarga kelas Login sampeyan mesthi ngasilake manawa pangguna ora mlebu. Sampeyan bali menyang kelas Login lan ngleksanakake sawetara kode kanggo verifikasi manawa pangguna wis mlebu. Ing kasus iki, sampeyan kudu ngerti carane ngisolasi modul iki. Saiki, cara paling gampang kanggo nindakake iki yaiku hardcode jeneng pangguna lan sandhi sing sampeyan gunakake ing tes sampeyan, lan yen cocog, banjur bali asil "pangguna wis mlebu." Sampeyan nggawe owah-owahan iki, mbukak loro tes, lan loro-lorone lulus. Ayo pindhah menyang langkah pungkasan: sampeyan ndeleng kode sing digawe, lan goleki cara kanggo ngatur maneh lan nyederhanakake. Dadi algoritma TDD yaiku:

1. Nggawe test.
2. Kita nulis kode kanggo tes iki.
3. Refactored kode.

kesimpulan

Iku kabeh aku pengin pitutur marang kowe bab testing unit lan TDD ing tataran iki. Ing kasunyatan, ana akeh kangelan sing digandhengake karo nyoba kanggo isolasi modul kode, wiwit kode bisa banget Komplek lan mbingungake. Sawetara kelas ana ing isolasi lengkap. Nanging, dheweke duwe dependensi, lan dependensi kasebut duwe dependensi, lan liya-liyane. Kanggo ngatasi kahanan kaya mengkono, para veteran TDD nggunakake mock, sing mbantu ngisolasi kelas individu kanthi ngganti obyek ing modul gumantung. Artikel iki mung ringkesan lan rada simplified introduksi kanggo testing unit lan TDD, kita ora bakal pindhah menyang rinci bab modul goblok lan Techniques TDD liyane. Ide iki kanggo menehi konsep dhasar lan prinsip TDD lan unit testing sing muga-muga sampeyan duwe. Asli - https://simpleprogrammer.com/2017/01/30/tdd-unit-testing/