Apakah itu TDD dan ujian unit [terjemahan]

Artikel ini adalah adaptasi daripada bab daripada buku Panduan Kerjaya Perisian Lengkap. Pengarangnya, John Sonmez, menulisnya dan menyiarkan beberapa bab di laman webnya.

Glosari pendek untuk pemula

Ujian unit atau ujian unit ialah proses dalam pengaturcaraan yang membolehkan anda menyemak modul individu bagi kod sumber program untuk memastikan ketepatannya. Ideanya adalah untuk menulis ujian untuk setiap fungsi atau kaedah yang tidak remeh. Ujian regresi ialah nama umum untuk semua jenis ujian perisian yang bertujuan untuk mengesan ralat dalam kawasan kod sumber yang telah diuji. Ralat sedemikian - apabila, selepas membuat perubahan pada program, sesuatu yang harus terus berfungsi berhenti berfungsi - dipanggil ralat regresi. Keputusan merah, gagal - kegagalan ujian. Perbezaan antara hasil yang diharapkan dan yang sebenar. Keputusan hijau, lulus - keputusan ujian positif. Hasil sebenar tidak berbeza dengan apa yang diperolehi. *** Saya mempunyai hubungan yang sangat bercampur dengan Test Driven Development (TDD) dan ujian unit, berubah daripada cinta kepada benci dan kembali lagi. Saya adalah peminat tegar dan pada masa yang sama seorang yang ragu-ragu tentang penggunaan ini, dan lain-lain, "amalan terbaik." Sebab sikap saya adalah berdasarkan fakta bahawa masalah serius telah muncul dalam proses pembangunan perisian: pembangun, dan kadangkala pengurus, menggunakan alat dan metodologi tertentu hanya kerana ia tergolong dalam "amalan terbaik". Sebab sebenar penggunaannya masih tidak jelas. Suatu hari saya mula bekerja pada projek tertentu, dan dalam proses itu saya dimaklumkan bahawa kami akan mengubah suai kod yang diliputi oleh sejumlah besar ujian unit. Bukan jenaka, terdapat kira-kira 3000 daripadanya. Ini biasanya petanda yang baik, isyarat bahawa pembangun menggunakan metodologi lanjutan. Kod dengan pendekatan ini paling kerap berstruktur, dan ia berdasarkan seni bina yang difikirkan dengan baik. Pendek kata, kehadiran ujian membuatkan saya gembira, jika hanya kerana ia bermakna memudahkan tugas saya sebagai mentor pengaturcara. Memandangkan kami sudah mempunyai ujian unit, apa yang saya perlu lakukan ialah menyambungkan pasukan pembangunan untuk menyokong mereka dan mula menulis kod kami sendiri. Saya membuka IDE (persekitaran pembangunan bersepadu) dan memuatkan projek. Ia adalah projek besar! Saya menjumpai folder berlabel "ujian unit". “Hebat,” saya fikir. - Mari kita lancarkan dan lihat apa yang berlaku. Ia hanya mengambil masa beberapa minit, dan yang mengejutkan saya, semua ujian lulus, semuanya berwarna hijau ( "hijau" adalah hasil positif ujian. Isyarat bahawa kod berfungsi seperti yang diharapkan. Merah menunjukkan "gagal" atau gagal, kemudian terdapat kes apabila kod tidak berfungsi dengan betul - nota penterjemah ). Mereka semua lulus ujian. Pada ketika itu, skeptik dalam diri saya bangun. Bagaimana pula, tiga ribu ujian unit, dan mereka mengambil semuanya sekaligus - dan memberikan keputusan yang positif? Dalam amalan lama saya, saya tidak dapat mengingati masa apabila saya mula bekerja pada projek tanpa ujian unit negatif tunggal dalam kod. Apa nak buat? Semak secara manual! ChY memilih satu ujian rawak, bukan yang paling mendedahkan, tetapi ia dengan serta-merta jelas apa yang dia semak. Tetapi semasa bekerja melaluinya, saya melihat sesuatu yang tidak masuk akal: ujian itu tidak mengandungi sebarang perbandingan dengan hasil yang diharapkan (menegaskan)! Iaitu, pada hakikatnya tiada apa yang disemak sama sekali ! Terdapat langkah-langkah tertentu dalam ujian, mereka telah dijalankan, tetapi pada akhir ujian, di mana dia harus membandingkan keputusan sebenar dan dijangka, tidak ada pemeriksaan. "Ujian" itu tidak menguji apa-apa. Saya membuka ujian lain. Lebih baik lagi: pengendali perbandingan dengan hasilnya telah diulas. dengan cemerlang! Ini adalah cara yang bagus untuk melakukan pas ujian, cuma ulas kod yang menyebabkannya gagal. Saya menyemak ujian lain, kemudian satu lagi... Tiada seorang pun daripada mereka menyemak apa-apa. Tiga ribu ujian, dan semuanya tidak berguna sama sekali. Terdapat perbezaan besar antara menulis ujian unit dan memahami ujian unit dan pembangunan dipacu ujian (TDD).

Apakah ujian unit?

Idea asas ujian unit adalah untuk menulis ujian yang menguji "unit" kod terkecil. Ujian unit biasanya ditulis dalam bahasa pengaturcaraan yang sama dengan kod sumber aplikasi. Mereka dicipta secara langsung untuk menguji kod ini. Iaitu, ujian unit ialah kod yang menyemak ketepatan kod lain. Saya menggunakan perkataan "ujian" dengan agak bebas dalam konteks, kerana ujian unit dalam erti kata tertentu bukanlah ujian. Mereka tidak mengalami apa-apa. Apa yang saya maksudkan ialah apabila anda menjalankan ujian unit anda biasanya tidak mendapati bahawa sesetengah kod tidak berfungsi. Anda menemui ini semasa menulis ujian, kerana anda akan menukar kod sehingga ujian bertukar hijau. Ya, kod mungkin berubah kemudian dan kemudian ujian anda mungkin gagal. Jadi dalam pengertian ini, ujian unit ialah ujian regresi. Ujian unit bukan seperti ujian biasa di mana anda mempunyai beberapa langkah yang akan anda ikuti dan anda melihat sama ada perisian berfungsi dengan betul atau tidak. Semasa proses menulis ujian unit, anda mengetahui sama ada kod itu melakukan perkara yang sepatutnya dilakukan atau tidak, dan anda akan menukar kod tersebut sehingga ujian itu lulus. Mengapa tidak menulis ujian unit dan semak sama ada ia lulus? Jika anda memikirkannya dengan cara ini, maka ujian unit bertukar menjadi beberapa jenis keperluan mutlak untuk modul kod tertentu pada tahap yang sangat rendah. Anda boleh menganggap ujian unit sebagai spesifikasi mutlak . Ujian unit menentukan bahawa di bawah keadaan ini, dengan set input tertentu ini, terdapat output yang perlu anda peroleh daripada unit kod ini. Ujian unit sebenar mengenal pasti unit koheren terkecil kod, yang dalam kebanyakan bahasa pengaturcaraan - sekurang-kurangnya berorientasikan objek - ialah kelas.

Apa yang kadangkala dipanggil ujian unit?

Ujian unit sering dikelirukan dengan ujian integrasi. Sesetengah "ujian unit" menguji lebih daripada satu kelas atau menguji unit kod yang besar. Banyak pembangun mendakwa bahawa mereka menulis ujian unit sedangkan sebenarnya mereka menulis ujian kotak putih peringkat rendah. Jangan berdebat dengan lelaki ini. Hanya ketahui bahawa mereka sebenarnya menulis ujian integrasi, dan ujian unit benar menguji unit terkecil kod secara berasingan daripada bahagian lain. Satu lagi perkara yang sering dipanggil ujian unit ialah ujian unit tanpa memeriksa nilai yang dijangkakan. Dalam erti kata lain, ujian unit yang sebenarnya tidak menguji apa-apa. Sebarang ujian, bersatu atau tidak, mesti menyertakan sejenis pengesahan - kami memanggilnya menyemak keputusan sebenar berbanding keputusan yang dijangkakan. Penyesuaian inilah yang menentukan sama ada ujian itu lulus atau gagal. Ujian yang sentiasa lalui tidak berguna. Ujian yang selalu gagal adalah sia-sia.

Nilai Pengujian Unit

Mengapa saya seorang peminat ujian unit? Mengapakah berbahaya untuk memanggil ujian umum, yang melibatkan ujian bukan blok terkecil yang diasingkan daripada kod lain, tetapi sekeping kod yang lebih besar, "ujian unit"? Apakah masalahnya jika beberapa ujian saya tidak membandingkan keputusan yang diterima dan dijangkakan? Sekurang-kurangnya mereka melaksanakan kod tersebut. Saya akan cuba menerangkan. Terdapat dua sebab utama untuk melaksanakan ujian unit. Yang pertama ialah menambah baik reka bentuk kod. Ingat bagaimana saya mengatakan bahawa ujian unit tidak benar-benar menguji? Apabila anda menulis ujian unit yang betul, anda memaksa diri anda untuk mengasingkan unit kod terkecil. Percubaan ini akan membawa anda menemui masalah dalam struktur kod itu sendiri. Anda mungkin merasa sangat sukar untuk mengasingkan kelas ujian dan tidak memasukkan kebergantungannya, dan ini mungkin membuatkan anda sedar bahawa kod anda digandingkan terlalu rapat. Anda mungkin mendapati bahawa fungsi teras yang anda cuba uji menjangkau berbilang modul, membawa anda untuk mempercayai bahawa kod anda tidak cukup koheren. Apabila anda duduk untuk menulis ujian unit, anda mungkin tiba-tiba mendapati (dan percayalah, ia berlaku!) bahawa anda tidak tahu apa yang sepatutnya dilakukan oleh kod tersebut. Oleh itu, anda tidak akan dapat menulis ujian unit untuknya. Dan sudah tentu, anda mungkin menemui pepijat sebenar dalam pelaksanaan kod, kerana ujian unit memaksa anda untuk berfikir di luar kotak dan menguji set input yang berbeza yang mungkin tidak anda pertimbangkan. Jika anda mematuhi peraturan "uji unit terkecil kod secara berasingan daripada yang lain" semasa membuat ujian unit, anda pasti akan menemui pelbagai masalah dengan kod itu dan reka bentuk modul tersebut. Dalam kitaran hayat pembangunan perisian, ujian unit lebih merupakan aktiviti penilaian daripada aktiviti ujian. Matlamat utama kedua ujian unit adalah untuk mencipta set ujian regresi automatik yang boleh bertindak sebagai spesifikasi peringkat rendah bagi tingkah laku perisian. Apakah maksudnya? Apabila anda menguli doh, anda tidak memecahkannya. Dari sudut pandangan ini, ujian unit adalah ujian, lebih khusus ujian regresi. Walau bagaimanapun, tujuan ujian unit bukan untuk membina ujian regresi sahaja. Dalam amalan, ujian unit jarang menangkap regresi, kerana perubahan pada unit kod yang anda uji hampir selalu mengandungi perubahan pada ujian unit itu sendiri. Ujian regresi jauh lebih berkesan pada tahap yang lebih tinggi, apabila kod diuji sebagai "kotak hitam", kerana pada tahap ini struktur dalaman kod boleh diubah, manakala tingkah laku luaran dijangka kekal sama. Ujian unit pula menyemak struktur dalaman, supaya apabila struktur itu berubah, ujian unit tidak gagal. Mereka menjadi tidak boleh digunakan dan kini perlu diubah, dibuang atau ditulis semula. Anda kini mengetahui lebih lanjut tentang tujuan sebenar ujian unit daripada banyak pembangun perisian veteran.

Apakah itu Test Driven Development (TDD)?

Dalam proses pembangunan perisian, spesifikasi yang baik sepadan dengan beratnya dalam emas. Pendekatan TDD ialah sebelum anda menulis sebarang kod, anda terlebih dahulu menulis ujian yang akan berfungsi sebagai spesifikasi, iaitu, tentukan apa yang perlu dilakukan oleh kod tersebut. Ini adalah konsep pembangunan perisian yang sangat berkuasa, tetapi ia sering disalahgunakan. Biasanya, pembangunan dipacu ujian bermaksud menggunakan ujian unit untuk membimbing penciptaan kod aplikasi. Tetapi sebenarnya, pendekatan ini boleh digunakan di mana-mana peringkat. Walau bagaimanapun, dalam artikel ini kami akan menganggap bahawa kami menggunakan ujian unit untuk aplikasi kami. Pendekatan TDD menghidupkan segala-galanya, dan bukannya menulis kod dahulu dan kemudian menulis ujian unit untuk menguji kod itu, anda menulis ujian unit dahulu dan kemudian menulis kod untuk menjadikan ujian itu hijau. Dengan cara ini, ujian unit "memacu" pembangunan kod. Proses ini diulang berulang kali. Anda menulis ujian lain yang mentakrifkan lebih banyak fungsi tentang perkara yang harus dilakukan oleh kod. Anda kemudian menulis dan mengubah suai kod untuk memastikan ujian selesai dengan jayanya. Sebaik sahaja anda mempunyai keputusan hijau, anda mula memfaktorkan semula kod, iaitu, memfaktor semula atau membersihkannya untuk menjadikannya lebih ringkas. Rangkaian proses ini sering dipanggil "Red-Green-Refactoring" kerana pertama ujian unit gagal (merah), kemudian kod ditulis untuk menyesuaikan diri dengan ujian, memastikan ia berjaya (hijau), dan akhirnya kod dioptimumkan ( pemfaktoran semula). .

Apakah matlamat TDD?

Pembangunan dipacu ujian (TDD), seperti ujian unit, boleh digunakan secara tidak betul. Sangat mudah untuk memanggil apa yang anda lakukan "TDD" dan juga mengikuti amalan tanpa memahami mengapa anda melakukannya dengan cara itu. Nilai terbesar TDD ialah ujian dilakukan untuk menghasilkan spesifikasi kualiti. TDD pada asasnya ialah amalan menulis spesifikasi tepat yang boleh disemak secara automatik sebelum pengekodan ditulis. Ujian adalah spesifikasi terbaik kerana ia tidak berbohong. Mereka tidak akan memberitahu anda selepas dua minggu siksaan dengan kod "bukan itu yang saya maksudkan sama sekali." Ujian, apabila ditulis dengan betul, sama ada lulus atau gagal. Ujian jelas menunjukkan apa yang harus berlaku dalam keadaan tertentu. Oleh itu, matlamat TDD adalah untuk memberi kita pemahaman yang lengkap tentang perkara yang perlu kita laksanakan sebelum kita mula melaksanakannya. Jika anda memulakan dengan TDD dan tidak dapat mengetahui ujian yang sepatutnya diuji, maka anda perlu bertanya lebih banyak soalan. Satu lagi peranan penting TDD ialah memelihara dan mengoptimumkan kod. Penyelenggaraan kod adalah mahal. Saya sering bergurau bahawa pengaturcara terbaik ialah orang yang menulis kod terpendek yang menyelesaikan beberapa masalah. Atau bahkan orang yang membuktikan bahawa masalah ini tidak perlu diselesaikan, dan dengan itu mengalih keluar kod sepenuhnya, kerana pengaturcara ini yang menemui cara yang betul untuk mengurangkan bilangan ralat dan mengurangkan kos penyelenggaraan aplikasi. Dengan menggunakan TDD, anda boleh benar-benar yakin bahawa anda tidak menulis sebarang kod yang tidak perlu, kerana anda hanya akan menulis kod untuk lulus ujian. Terdapat prinsip pembangunan perisian yang dipanggil YAGNI (anda tidak akan memerlukannya). TDD menghalang YAGNI.

Aliran Kerja Pembangunan Didorong Ujian (TDD) Biasa

Memahami maksud TDD dari sudut akademik semata-mata adalah sukar. Jadi mari kita lihat contoh sesi TDD. Bayangkan duduk di meja anda dan dengan cepat melakar apa yang anda fikir akan menjadi reka bentuk peringkat tinggi untuk ciri yang membolehkan pengguna log masuk ke aplikasi dan menukar kata laluan mereka jika mereka terlupa. Anda memutuskan bahawa anda akan bermula dengan pelaksanaan pertama fungsi log masuk, mewujudkan kelas yang akan mengendalikan semua logik untuk proses log masuk. Anda membuka editor kegemaran anda dan membuat ujian unit yang dipanggil "Log masuk kosong menghalang pengguna daripada log masuk." Anda menulis kod ujian unit yang mula-mula mencipta contoh kelas Log Masuk (yang anda belum buat lagi). Anda kemudian menulis kod untuk memanggil kaedah dalam kelas Log masuk yang melepasi nama pengguna dan kata laluan kosong. Akhir sekali, anda menulis semakan terhadap hasil yang dijangkakan, menyemak bahawa pengguna dengan log masuk kosong sebenarnya tidak log masuk. Anda cuba menjalankan ujian, tetapi ia tidak dikompilasi kerana anda tidak mempunyai kelas Log Masuk. Anda membetulkan keadaan ini dan mencipta kelas Log masuk bersama-sama dengan kaedah dalam kelas itu untuk log masuk dan satu lagi untuk menyemak status pengguna untuk melihat sama ada mereka log masuk. Setakat ini anda belum melaksanakan fungsi kelas ini dan kaedah yang kami perlukan. Anda menjalankan ujian pada ketika ini. Sekarang ia menyusun, tetapi serta-merta gagal. Sekarang anda kembali ke kod dan melaksanakan fungsi untuk lulus ujian. Dalam kes kami, ini bermakna kami harus mendapat keputusan: "pengguna tidak log masuk." Anda menjalankan ujian sekali lagi dan kini ia lulus. Mari kita beralih ke ujian seterusnya. Sekarang mari kita bayangkan bahawa anda perlu menulis ujian yang dipanggil "Pengguna dilog masuk jika mereka memasukkan nama pengguna dan kata laluan yang sah." Anda menulis ujian unit yang menjadikan kelas Log masuk dan cuba log masuk dengan nama pengguna dan kata laluan. Dalam ujian unit, anda menulis pernyataan bahawa kelas Log masuk harus menjawab ya kepada soalan sama ada pengguna log masuk. Anda menjalankan ujian baru ini dan sudah tentu ia gagal kerana kelas Log masuk anda sentiasa mengembalikan bahawa pengguna tidak log masuk. Anda kembali ke kelas Log masuk anda dan laksanakan beberapa kod untuk mengesahkan bahawa pengguna telah log masuk. Dalam kes ini, anda perlu memikirkan cara mengasingkan modul ini. Buat masa ini, cara paling mudah untuk melakukan ini ialah mengekod keras nama pengguna dan kata laluan yang anda gunakan dalam ujian anda, dan jika ia sepadan, kemudian kembalikan hasil "pengguna dilog masuk." Anda membuat perubahan ini, jalankan kedua-dua ujian dan kedua-duanya lulus. Mari kita beralih ke langkah terakhir: anda melihat kod yang dijana dan mencari cara untuk menyusun semula dan memudahkannya. Jadi algoritma TDD ialah:

1. Mencipta ujian.
2. Kami menulis kod untuk ujian ini.
3. Memfaktorkan semula kod.

kesimpulan

Itu sahaja yang saya ingin beritahu anda tentang ujian unit dan TDD pada peringkat ini. Sebenarnya, terdapat banyak kesukaran yang berkaitan dengan cuba mengasingkan modul kod, kerana kod itu boleh menjadi sangat kompleks dan mengelirukan. Sangat sedikit kelas wujud dalam pengasingan lengkap. Sebaliknya, mereka mempunyai tanggungan, dan tanggungan tersebut mempunyai tanggungan, dan sebagainya. Untuk menangani situasi sedemikian, veteran TDD menggunakan olok-olok, yang membantu mengasingkan kelas individu dengan menggantikan objek dalam modul bergantung. Artikel ini hanyalah gambaran keseluruhan dan pengenalan yang agak dipermudahkan kepada ujian unit dan TDD, kami tidak akan menerangkan secara terperinci tentang modul dummy dan teknik TDD yang lain. Idea ini adalah untuk memberi anda konsep dan prinsip asas TDD dan ujian unit yang diharapkan anda miliki sekarang. Asal - https://simpleprogrammer.com/2017/01/30/tdd-unit-testing/