Pembangunan Bergerak Uji
Test Driven Development (TDD) adalah pendekatan pengembangan perisian di mana kes ujian dikembangkan untuk menentukan dan mengesahkan apa yang akan dilakukan kod. Secara sederhana, kes ujian untuk setiap fungsi dibuat dan diuji terlebih dahulu dan jika ujian gagal maka kod baru ditulis untuk lulus ujian dan menjadikan kod mudah dan bebas bug.
Pengembangan Didorong oleh Ujian dimulakan dengan merancang dan mengembangkan ujian untuk setiap fungsi kecil aplikasi. TDD memerintahkan pemaju untuk menulis kod baru hanya jika ujian automatik gagal. Ini mengelakkan pertindihan kod. Bentuk lengkap TDD adalah pengembangan berdasarkan Ujian.
Konsep mudah TDD adalah menulis dan membetulkan ujian yang gagal sebelum menulis kod baru (sebelum pengembangan). Ini membantu mengelakkan pertindihan kod kerana kita menulis sebilangan kecil kod sekaligus untuk lulus ujian. (Ujian hanyalah syarat syarat yang perlu kita uji untuk menunaikannya).
Pengembangan Didorong oleh Ujian adalah proses mengembangkan dan menjalankan ujian automatik sebelum pengembangan sebenar aplikasi. Oleh itu, TDD kadang-kadang disebut juga sebagai Ujian Pembangunan Pertama.
Dalam tutorial ini, anda akan belajar lebih banyak mengenai-
- Cara melaksanakan Ujian TDD
- TDD Vs. Ujian Tradisional
- Apa itu TDD penerimaan dan TDD Pembangun
- Meningkatkan TDD melalui Pembangunan Model Dipandu Agile (AMDD)
- Pembangunan Bergerak Uji (TDD) Vs. Pembangunan Bergerak Model Agile (AMDD)
- Contoh TDD
- Kebaikan TDD
Cara melaksanakan Ujian TDD
Langkah-langkah berikut menentukan cara melakukan ujian TDD,
- Tambah ujian.
- Jalankan semua ujian dan lihat sama ada ujian baru gagal.
- Tuliskan beberapa kod.
- Jalankan ujian dan kod Refaktor.
- Ulangi.
Kitaran TDD mentakrifkan
- Tuliskan ujian
- Jadikan ia berjalan.
- Tukar kod untuk menjadikannya betul iaitu Refactor.
- Proses ulangan.
Beberapa penjelasan mengenai TDD:
- TDD bukan mengenai "Pengujian" dan juga mengenai "Reka Bentuk".
- TDD tidak bermaksud "menulis beberapa ujian, kemudian membina sistem yang lulus ujian.
- TDD tidak bermaksud "melakukan banyak Ujian."
TDD Vs. Ujian Tradisional
Pendekatan TDD terutamanya teknik spesifikasi. Ini memastikan bahawa kod sumber anda diuji secara menyeluruh pada tahap pengesahan.
- Dengan ujian tradisional, ujian yang berjaya menemui satu atau lebih kecacatan. Ia sama dengan TDD. Apabila ujian gagal, anda telah membuat kemajuan kerana anda tahu bahawa anda perlu menyelesaikan masalahnya.
- TDD memastikan bahawa sistem anda benar-benar memenuhi keperluan yang ditentukan untuknya. Ini membantu membina keyakinan anda terhadap sistem anda.
- Dalam TDD lebih banyak tumpuan adalah pada kod pengeluaran yang mengesahkan sama ada ujian akan berjalan dengan baik. Dalam pengujian tradisional, tumpuan lebih kepada reka bentuk kes ujian. Adakah ujian akan menunjukkan pelaksanaan aplikasi yang betul / tidak betul untuk memenuhi syarat.
- Dalam TDD, anda mencapai ujian liputan 100%. Setiap baris kod diuji, tidak seperti ujian tradisional.
- Kombinasi kedua-dua ujian tradisional dan TDD membawa kepada pentingnya menguji sistem daripada kesempurnaan sistem.
- Dalam Agile Modeling (AM), anda harus "menguji dengan tujuan". Anda harus tahu mengapa anda menguji sesuatu dan tahap mana yang perlu diuji.
Apa itu TDD penerimaan dan TDD Pembangun
Terdapat dua tahap TDD
- Penerimaan TDD (ATDD): Dengan ATDD anda menulis ujian penerimaan tunggal. Ujian ini memenuhi kehendak spesifikasi atau memenuhi tingkah laku sistem. Selepas itu tuliskan cukup kod pengeluaran / fungsi untuk memenuhi ujian penerimaan itu. Ujian penerimaan memberi tumpuan kepada keseluruhan tingkah laku sistem. ATDD juga dikenali sebagai Behavioral Driven Development (BDD).
- Pembangun TDD: Dengan Pembangun TDD anda menulis ujian pemaju tunggal iaitu ujian unit dan kemudian kod pengeluaran yang cukup untuk memenuhi ujian itu. Ujian unit memberi tumpuan kepada setiap fungsi kecil sistem. Pembangun TDD hanya dipanggil sebagai TDD.
Matlamat utama ATDD dan TDD adalah untuk menentukan keperluan terperinci dan dapat dilaksanakan untuk penyelesaian anda tepat pada masanya (JIT). JIT bermaksud hanya mempertimbangkan keperluan yang diperlukan dalam sistem. Jadi tingkatkan kecekapan.
Meningkatkan TDD melalui Pembangunan Model Dipandu Agile (AMDD)
TDD sangat baik dalam spesifikasi dan pengesahan terperinci. Ia gagal memikirkan masalah yang lebih besar seperti reka bentuk keseluruhan, penggunaan sistem, atau UI. AMDD menangani masalah skala Agile yang TDD tidak.
Oleh itu, AMDD digunakan untuk masalah yang lebih besar.
Kitaran hidup AMDD.
Dalam Model-driven Development (MDD), model yang luas dibuat sebelum kod sumber ditulis. Yang seterusnya mempunyai pendekatan tangkas?
Dalam gambar di atas, setiap kotak mewakili aktiviti pengembangan.
Membayangkan adalah salah satu proses TDD untuk meramalkan / membayangkan ujian yang akan dilakukan pada minggu pertama projek. Matlamat utama membayangkan adalah untuk mengenal pasti ruang lingkup sistem dan seni bina sistem. Keperluan tahap tinggi dan pemodelan seni bina dilakukan untuk berjaya membayangkan.
Ini adalah proses di mana tidak dilakukan spesifikasi terperinci mengenai perisian / sistem tetapi meneroka keperluan perisian / sistem yang menentukan strategi keseluruhan projek.
- Pengulangan 0: Membayangkan
Terdapat dua sub-aktif utama.
- Keperluan awal membayangkan.
Mungkin memerlukan beberapa hari untuk mengenal pasti keperluan dan skop sistem peringkat tinggi. Fokus utama adalah untuk meneroka model penggunaan, model domain awal, dan model antara muka pengguna (UI).
- Pembinaan Seni Bina Awal.
Ia juga memerlukan beberapa hari untuk mengenal pasti seni bina sistem. Ia membolehkan menetapkan petunjuk teknikal untuk projek tersebut. Fokus utama adalah untuk meneroka diagram teknologi, aliran Antaramuka Pengguna (UI), model domain, dan kes Ubah.
- Pemodelan pengulangan:
Di sini pasukan mesti merancang kerja yang akan dilakukan untuk setiap lelaran.
- Proses tangkas digunakan untuk setiap lelaran, iaitu semasa setiap lelaran, item kerja baru akan ditambahkan dengan keutamaan.
- Kerja yang diutamakan lebih tinggi pertama akan diambil kira. Item kerja yang ditambahkan boleh diprioritaskan atau dikeluarkan dari timbunan item pada bila-bila masa.
- Pasukan ini membincangkan bagaimana mereka akan melaksanakan setiap keperluan. Pemodelan digunakan untuk tujuan ini.
- Analisis pemodelan dan reka bentuk dilakukan untuk setiap keperluan yang akan dilaksanakan untuk iterasi tersebut.
- Model menyerbu:
Ini juga dikenali sebagai Pemodelan Just in time.
- Di sini sesi pemodelan melibatkan pasukan 2/3 ahli yang membincangkan masalah di atas kertas atau papan putih.
- Seorang ahli pasukan akan meminta yang lain untuk membuat model dengan mereka. Sesi pemodelan ini akan memakan masa lebih kurang 5 hingga 10 minit. Tempat ahli pasukan berkumpul untuk berkongsi papan putih / kertas.
- Mereka meneroka masalah sehingga mereka tidak menemui punca utama masalah tersebut. Tepat pada waktunya, jika satu ahli pasukan mengenal pasti masalah yang ingin diselesaikannya, dia akan segera mendapatkan bantuan daripada ahli pasukan lain.
- Ahli kumpulan yang lain kemudiannya mengupas masalahnya dan kemudian semua orang meneruskannya seperti sebelumnya. Ia juga disebut sebagai sesi pemodelan berdiri atau QA pelanggan.
- Pembangunan Bergerak Uji (TDD).
- Ini mempromosikan pengesahan kod aplikasi anda dan spesifikasi terperinci.
- Uji penerimaan (keperluan terperinci) dan ujian pemaju (ujian unit) adalah input untuk TDD.
- TDD menjadikan kodnya lebih mudah dan jelas. Ini membolehkan pembangun menyimpan lebih sedikit dokumentasi.
- Ulasan.
- Ini adalah pilihan. Ia merangkumi pemeriksaan kod dan tinjauan model.
- Ini boleh dilakukan untuk setiap lelaran atau untuk keseluruhan projek.
- Ini adalah pilihan yang baik untuk memberi maklum balas untuk projek tersebut.
Pembangunan Bergerak Uji (TDD) Vs. Pembangunan Bergerak Model Agile (AMDD)
| TDD | AMDD |
|
|
|
|
|
|
|
|
|
|
|
|
| -------------------------------------------- |
Contoh TDD
Di sini dalam contoh ini, kita akan menentukan kata laluan kelas. Untuk kelas ini, kami akan berusaha memenuhi syarat berikut.
Syarat untuk penerimaan Kata Laluan:
- Kata laluan hendaklah antara 5 hingga 10 aksara.
Pertama, kami menulis kod yang memenuhi semua syarat di atas.
Senario 1 : Untuk menjalankan ujian, kami membuat kelas PasswordValidator ();
Kami akan berjalan di atas kelas TestPassword ();
Output LULUS seperti gambar di bawah;
Keluaran :
Senario 2 : Di sini kita dapat melihat dalam metode TestPasswordLength () tidak perlu membuat contoh kelas PasswordValidator. Contoh bermaksud membuat objek kelas untuk merujuk anggota (pemboleh ubah / kaedah) kelas tersebut.
Kami akan membuang kelas PasswordValidator pv = PasswordValidator baru () dari kod. Kita boleh memanggil kaedah isValid () secara langsung oleh PasswordValidator. IsValid ("Abc123") . (Lihat gambar di bawah)
Oleh itu, kami Refactor (ubah kod) seperti di bawah:
Senario 3 : Setelah memfaktur semula output menunjukkan status yang gagal (lihat gambar di bawah) ini kerana kami telah membuang contohnya. Oleh itu, tidak ada rujukan untuk kaedah bukan statik iaituValid ().
Oleh itu, kita perlu mengubah kaedah ini dengan menambahkan kata "statik" sebelum Boolean sebagai isvalid boolean statik awam (String password). Refactoring Class PasswordValidator () untuk menghilangkan ralat di atas untuk lulus ujian.
Pengeluaran:
Setelah membuat perubahan pada kelas PassValidator () jika kita menjalankan ujian maka output akan LULUS seperti yang ditunjukkan di bawah.
Kelebihan TDD
- Pemberitahuan pepijat awal.
Pembangun menguji kod mereka tetapi dalam dunia pangkalan data, ini sering terdiri daripada ujian manual atau skrip sekali. Dengan menggunakan TDD, anda membina, dari masa ke masa, sekumpulan ujian automatik yang anda dan pembangun lain boleh jalankan sesuka hati.
- Reka bentuk yang lebih baik, lebih bersih dan lebih luas.
- Ini membantu memahami bagaimana kod tersebut akan digunakan dan bagaimana ia berinteraksi dengan modul lain.
- Ini menghasilkan keputusan reka bentuk yang lebih baik dan kod yang lebih dapat dikekalkan.
- TDD membenarkan menulis kod yang lebih kecil yang mempunyai tanggungjawab tunggal dan bukannya prosedur monolitik dengan pelbagai tanggungjawab. Ini menjadikan kod lebih mudah difahami.
- TDD juga memaksa hanya menulis kod pengeluaran untuk lulus ujian berdasarkan keperluan pengguna.
- Keyakinan kepada Reaktor
- Sekiranya anda menggunakan kod refaktor, kemungkinan terdapat kemungkinan kerosakan dalam kod tersebut. Oleh itu, dengan satu set ujian automatik, anda dapat memperbaiki jeda sebelum dilepaskan. Amaran yang betul akan diberikan sekiranya terdapat jeda ketika ujian automatik digunakan.
- Menggunakan TDD, seharusnya menghasilkan kod yang lebih cepat dan lebih luas dengan sedikit bug yang dapat diperbaharui dengan risiko minimum.
- Bagus untuk kerja berpasukan
Sekiranya tiada ahli pasukan, ahli pasukan lain dapat dengan mudah mengambil dan mengerjakan kod tersebut. Ini juga membantu perkongsian pengetahuan, sehingga menjadikan pasukan lebih efektif secara keseluruhan.
- Baik untuk Pemaju
Walaupun pembangun harus menghabiskan lebih banyak masa dalam menulis kes ujian TDD, ia memerlukan lebih sedikit masa untuk melakukan debug dan mengembangkan ciri baru. Anda akan menulis kod yang lebih bersih dan tidak rumit.
Ringkasan:
- TDD bermaksud pengembangan berdasarkan Ujian. Ini adalah proses mengubah kod untuk lulus ujian yang dirancang sebelumnya.
- Ia lebih menekankan pada kod pengeluaran dan bukannya reka bentuk kes ujian.
- Pengembangan berdasarkan ujian adalah proses mengubah kod untuk lulus ujian yang dirancang sebelumnya.
- Dalam Kejuruteraan Perisian, kadang-kadang dikenali sebagai "Uji Perkembangan Pertama."
- TDD merangkumi pemfaktoran semula kod iaitu mengubah / menambahkan sejumlah kod ke kod yang ada tanpa mempengaruhi tingkah laku kod tersebut.
- TDD apabila digunakan, kod menjadi lebih jelas dan mudah difahami.
Artikel ini disumbangkan oleh Kanchan Kulkarni