Apa itu Pengembangan Bergerak Uji (TDD)? Tutorial dengan Contoh

Apa itu Pengembangan Bergerak Uji (TDD)?

Pembangunan Bergerak Uji (TDD) adalah pendekatan pengembangan perisian di mana kes ujian dikembangkan untuk menentukan dan mengesahkan apa yang akan dilakukan kod tersebut. 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.

Pembangunan Bergerak Uji bermula dengan merancang dan mengembangkan ujian untuk setiap fungsi kecil aplikasi. Rangka kerja TDD mengarahkan 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 tidak lain adalah syarat syarat yang perlu kita uji untuk memenuhinya).

Pengembangan Didorong oleh Ujian adalah proses pengembangan dan menjalankan ujian automatik sebelum pengembangan sebenar aplikasi. Oleh itu, TDD kadang-kadang disebut sebagai Uji Perkembangan Pertama.

Dalam tutorial ini, anda akan belajar lebih banyak mengenai-

Cara melaksanakan Ujian TDD

Langkah-langkah berikut menentukan cara melakukan ujian TDD,

  1. Tambah ujian.
  2. Jalankan semua ujian dan lihat apakah ada ujian baru yang gagal.
  3. Tulis beberapa kod.
  4. Jalankan ujian dan kod Refaktor.
  5. Ulangi.

Lima Langkah Pembangunan Bergerak Uji

Kitaran TDD mentakrifkan

  1. Tuliskan ujian
  2. Jadikan ia berjalan.
  3. Tukar kod untuk membuatnya betul iaitu Refactor.
  4. Proses ulangan.

Beberapa penjelasan mengenai TDD:

  • Pendekatan TDD bukan mengenai 'Pengujian' atau 'Reka Bentuk'.
  • TDD tidak bermaksud 'menulis beberapa ujian, kemudian membina sistem yang lulus ujian.
  • TDD tidak bermaksud 'melakukan banyak Ujian.'

TDD Vs. Ujian Tradisional

Berikut adalah perbezaan utama antara pengembangan berdasarkan Uji dan 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 pengujian 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 Pemodelan Agile (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

  1. 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 Pembangunan Berteraskan Tingkah Laku (BDD) .
  2. Pembangun TDD: Dengan TDD Pembangun, anda menulis ujian pemaju tunggal iaitu ujian unit dan hanya kod pengeluaran yang mencukupi untuk memenuhi ujian tersebut. Ujian unit memberi tumpuan kepada setiap fungsi kecil sistem. Pembangun TDD dipanggil sebagai TDD.

    Matlamat utama ATDD dan TDD adalah untuk menentukan keperluan terperinci dan dapat dilaksanakan untuk penyelesaian anda secara tepat waktu (JIT). JIT bermaksud hanya mempertimbangkan keperluan yang diperlukan dalam sistem. Jadi tingkatkan kecekapan.

Meningkatkan skala TDD melalui Agile Model Driven Development (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 lincah?

Pada gambar di atas, setiap kotak mewakili aktiviti pengembangan.

Membayangkan adalah salah satu proses TDD 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 perisian / sistem tetapi meneroka keperluan perisian / sistem yang menentukan strategi keseluruhan projek.

Pengulangan 0: Membayangkan

Terdapat dua sub-aktif utama.

  1. 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).

  2. 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 masanya, jika seorang ahli pasukan mengenal pasti masalah yang ingin diselesaikannya, dia akan segera mendapatkan bantuan daripada ahli pasukan lain.
  • Ahli kumpulan yang lain kemudiannya mengupas isu tersebut 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 pembangun (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 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
  • TDD memendekkan gelung maklum balas pengaturcaraan
  • AMDD memendekkan gelung maklum balas pemodelan.
  • TDD adalah spesifikasi terperinci
  • AMDD berfungsi untuk masalah yang lebih besar
  • TDD mempromosikan pengembangan kod berkualiti tinggi
  • AMDD mempromosikan komunikasi berkualiti tinggi dengan pihak berkepentingan dan pemaju.
  • TDD bercakap dengan pengaturcara
  • TDD tidak berorientasikan visual
  • AMDD berorientasikan visual
  • TDD mempunyai ruang lingkup terhad untuk kerja perisian
  • AMDD mempunyai skop yang luas termasuk pihak berkepentingan. Ini melibatkan berusaha ke arah pemahaman bersama
  • Kedua-duanya menyokong perkembangan evolusi
--------------------------------------------

Sekarang, mari kita pelajari Pengembangan Bergerak Uji dengan contoh.

Contoh TDD

Di sini dalam contoh Pengujian Bergerak Uji ini, kami 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 dalam contoh TDD ini, 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;

Pengeluaran :

Senario 2 : Di sini kita dapat melihat dalam metode TestPasswordLength () tidak perlu membuat contoh kelas PasswordValidator. Contoh bermaksud mencipta objek kelas untuk merujuk anggota (pemboleh ubah / kaedah) kelas tersebut.

Kami akan membuang kelas PasswordValidator pv = PasswordValidator baru () dari kod. Kita boleh memanggil ianya sah () kaedah secara langsung oleh Kata Laluan Pengesah. 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. Jadi tidak ada rujukan untuk bukan-statik kaedah ianya sah ().

Oleh itu, kita perlu mengubah kaedah ini dengan menambahkan perkataan 'statik' sebelum Boolean sebagai boolean static awam isValid (String password). Refactoring Class PasswordValidator () untuk menghilangkan ralat di atas untuk lulus ujian.

Pengeluaran:

Setelah membuat perubahan pada PassValidator kelas () jika kita menjalankan ujian maka output akan LULUS seperti yang ditunjukkan di bawah.

Kelebihan TDD

Berikut adalah kelebihan utama Pengujian Bergerak dalam Kejuruteraan Perisian:

  • 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 baik.
    • TDD membenarkan menulis kod yang lebih kecil yang mempunyai tanggungjawab tunggal berbanding prosedur monolitik dengan pelbagai tanggungjawab. Ini menjadikan kod lebih mudah difahami.
    • TDD juga memaksa untuk menulis hanya 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 boleh 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 tidak ada 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.
  • Makna TDD: Ini adalah proses mengubah kod untuk lulus ujian yang dirancang sebelumnya.
  • Ia lebih menekankan pada kod pengeluaran dan bukannya reka bentuk kes ujian.
  • Pembangunan berdasarkan ujian adalah proses mengubah kod untuk lulus ujian yang dirancang sebelumnya.
  • Dalam Kejuruteraan Perisian, kadang-kadang dikenali sebagai 'Uji Perkembangan Pertama.'
  • Pengujian TDD merangkumi pemfaktoran semula kod iaitu mengubah / menambahkan sejumlah kod ke kod yang ada tanpa mempengaruhi tingkah laku kod tersebut.
  • Pengaturcaraan TDD apabila digunakan, kod menjadi lebih jelas dan mudah difahami.

Artikel ini disumbangkan oleh Kanchan Kulkarni