Kebaikan dan Kekurangan Pembangunan Bergerak Uji

Apa kebaikan dan keburukan Test Driven Development (TDD)?

Test Driven Development adalah metodologi pengembangan perisian di mana anda menulis dan lari satu set ujian sebelum anda menulis kod.

Ideanya adalah bahawa ujian itu akan gagal pada mulanya dan kemudian anda mula menulis kod yang cukup untuk mencuba semua ujian lulus. Setelah semua ujian lulus dapat menjadi ukuran kriteria yang telah dilakukan (dev-done) dan juga meningkatkan keyakinan terhadap kualiti kod tersebut.

Yang mengatakan, seperti metodologi pembangunan lain ada beberapa kebaikan dan keburukan yang berkaitan dengan TDD. Di sini, kami menyenaraikan beberapa perkara, tetapi sebelum itu, yang terbaik adalah menjelaskan beberapa perkara:

• Melakukan ujian unit tidak bermaksud melakukan TDD. Anda boleh melakukan yang pertama tanpa yang kedua. Sebenarnya, anda boleh melakukan TDD tanpa pengujian unit (tetapi kebanyakan orang lakukan), dalam kes ini, orang melengkapkan pengujian unit secara amnya dengan rasa ujian yang lain. Apa yang anda perlukan pasti adalah ujian automatik, apa sahaja.
• Anda boleh melakukan TDD untuk ujian kotak putih, untuk menguji kod anda. Tetapi anda juga boleh melakukan TDD untuk ujian kotak hitam, sesuatu yang sering disebut Behavior Driven Development.

Secara tradisinya, prosesnya adalah membuat kod banyak modul dan kemudian menulis ujian unit untuk mengesahkan kod tersebut. Ini adalah kaedah kod-pertama, uji kemudian. Tetapi jika selepas pengekodan tidak ada waktu atau anda terdesak untuk dilepaskan, maka keseluruhan pengujian unit dilewati, atau paling baik dilakukan secara retrospektif.

Sekarang, mengenai kebaikan dan keburukan TDD:

Kebaikan Pembangunan Bergerak Uji

• Kerana anda menulis ujian kecil pada satu masa, ini memaksa kod anda menjadi lebih modular (jika tidak, mereka sukar untuk diuji). TDD membantu anda mempelajari, memahami, dan menginternalisasi prinsip utama reka bentuk modular yang baik.
• TDD juga memaksa seni bina yang baik. Untuk menjadikan unit kod anda dapat diuji, mesti dikodulasi dengan betul. Menulis ujian terlebih dahulu, pelbagai masalah seni bina cenderung muncul lebih awal.
• Mendokumentasikan kod anda lebih baik daripada dokumentasi (ia tidak ketinggalan zaman kerana anda menggunakannya sepanjang masa).
• Menjadikan kod lebih senang dijaga dan dipantulkan. TDD membantu memberikan kejelasan semasa proses pelaksanaan dan menyediakan jaring pengaman ketika anda ingin memfaktur semula kod yang baru anda tulis.
• Menjadikan kolaborasi lebih mudah dan cekap, ahli pasukan dapat saling mengedit kod dengan yakin kerana ujian akan memberitahu mereka jika perubahan membuat kod tersebut berkelakuan dengan cara yang tidak dijangka.
• Kerana TDD pada dasarnya memaksa anda untuk menulis ujian unit sebelum menulis kod pelaksanaan, pemfaktoran semula kod menjadi lebih mudah dan cepat. Refactoring code yang ditulis dua tahun lalu adalah keras . Sekiranya kod itu disokong oleh satu set ujian unit yang baik, prosesnya akan dibuat lebih mudah.
• Membantu mencegah kecacatan - baik, paling tidak ia membantu anda mencari masalah reka bentuk atau keperluan pada awalnya. TDD memberikan amaran awal untuk masalah reka bentuk (apabila lebih mudah diperbaiki).
• Membantu pengaturcara benar-benar memahami kod mereka.
• Membuat suite ujian regresi automatik, pada dasarnya percuma. anda tidak perlu meluangkan masa selepas itu menulis ujian unit untuk menguji kod pelaksanaan.
• Ini mendorong langkah-langkah kecil dan memperbaiki reka bentuk kerana ini menjadikan anda memotong pergantungan yang tidak perlu untuk memudahkan penyediaannya.
• Ini membantu menjelaskan keperluan kerana anda harus mengetahui secara pasti input apa yang harus anda berikan dan output apa yang anda harapkan.
• Ujian unit sangat berharga sebagai jaring pengaman apabila kodnya perlu diubah untuk menambah ciri baru atau memperbaiki bug yang ada. Oleh kerana penyelenggaraan merangkumi antara 60 dan 90% dari kitaran hayat perisian, sukar untuk membesar-besarkan bagaimana masa yang diperlukan untuk membuat satu set ujian unit yang layak dapat membayarnya berulang kali sepanjang hayat projek.
• Menguji semasa menulis juga memaksa anda untuk mencuba menjadikan antarmuka anda cukup bersih untuk diuji. Kadang-kadang sukar untuk melihat kelebihannya sehingga anda menggunakan kod yang tidak dilakukan, dan satu-satunya cara untuk melakukan latihan dan fokus pada sekeping kod adalah dengan menjalankan keseluruhan sistem dan menetapkan titik putus .
• Kesalahan 'Bodoh' segera dikesan. Ini membantu pembangun mencari kesilapan yang akan membuang masa semua orang jika mereka dijumpai di QA.

Kekurangan Pembangunan Bergerak Uji

• Suite ujian itu sendiri mesti dijaga; ujian mungkin tidak sepenuhnya deterministik (iaitu bergantung pada pergantungan luaran).
• Ujiannya mungkin sukar ditulis, terutamanya. melebihi tahap pengujian unit.
• Pada mulanya, ia melambatkan pembangunan; untuk persekitaran permulaan yang berulang-ulang, kod pelaksanaan mungkin tidak siap untuk beberapa waktu kerana menghabiskan masa menulis ujian terlebih dahulu. (Tetapi dalam jangka panjang, ia mempercepat pembangunan)
• Seperti mana-mana pengaturcaraan, terdapat perbezaan besar antara melakukannya dan melakukannya dengan baik. Menulis ujian unit yang baik adalah bentuk seni. Aspek TDD ini sering tidak dibincangkan, banyak pengurus cenderung memberi tumpuan kepada metrik seperti liputan kod; metrik tersebut tidak memberitahu anda mengenai kualiti ujian unit.
• Ujian unit adalah sesuatu yang perlu dibeli oleh seluruh pasukan.
• Satu cabaran untuk belajar. Ia boleh menakutkan dan tidak mudah bagi seseorang untuk belajar pada mulanya, terutamanya berusaha mempelajarinya sendiri. Ia memerlukan banyak dedikasi (disiplin, latihan, ketekunan) dan anda harus mempunyai matlamat yang anda mahukan untuk terus menjadi lebih baik.
• Sukar untuk digunakan pada kod warisan yang ada.
• Banyak kesalahpahaman yang membuat pengaturcara tidak mempelajarinya.
• Sukar untuk mula bekerja dengan cara ini. Terutama jika anda bertahun-tahun bekerja dengan cara lain.
• Anda kadang-kadang harus mengejek banyak perkara atau perkara yang sukar untuk diejek. Ia bermanfaat dalam jangka masa panjang, tetapi menyakitkan sekarang.
• Anda mesti melakukan pengemasan secara berterusan. Oleh kerana menempah lebih banyak ujian menjadikan bangunan anda lebih lama dan lebih lama, adalah perlu untuk menyempurnakan ujian tersebut agar ujian itu berjalan lebih cepat atau untuk membuang ujian yang berlebihan.
• Seperti teknik yang baik, pengujian unit dapat dilakukan secara ekstrem. Manfaat terbesar datang dari usaha yang sederhana, dengan ujian selalu menggunakan kod dengan cara semudah mungkin. Sekiranya anda sering menguji semula ujian anda, ada kemungkinan anda menghabiskan terlalu banyak masa di suite ujian.
• Sangat mudah untuk terganggu oleh 'fluff' atau ciri-ciri mewah dalam kerangka pengujian unit. Kita harus ingat bahawa ujian mudah adalah yang paling cepat dibuat dan yang paling mudah dikendalikan.
• Walaupun benar-benar diperlukan, membuat ujian untuk kegagalan dapat membosankan, tetapi akhirnya menghasilkan banyak masa.
• Refactoring peringkat awal memerlukan kelas ujian refactoring juga.
• Melainkan jika semua orang dalam pasukan menjalankan ujian mereka dengan betul, keseluruhan sistem dapat merosot dengan cepat.