Di mana saya harus menarik garis antara tes unit dan tes integrasi? Haruskah mereka terpisah?


11

Saya memiliki kerangka kerja MVC kecil yang telah saya kerjakan. Itu basis kode pasti tidak besar, tetapi tidak lagi hanya beberapa kelas. Saya akhirnya memutuskan untuk mengambil risiko dan mulai menulis tes untuk itu (ya, saya tahu saya harus melakukan itu selama ini, tapi API itu super tidak stabil sampai sekarang)

Bagaimanapun, rencana saya adalah membuatnya sangat mudah untuk diuji, termasuk tes integrasi. Contoh uji integrasi akan menghasilkan sesuatu seperti ini:

Objek permintaan HTTP palsu -> kerangka kerja MVC -> objek respons HTTP -> periksa responsnya benar

Karena ini semua bisa dilakukan tanpa keadaan atau alat khusus (otomatisasi browser dll), saya sebenarnya bisa melakukan ini dengan mudah dengan kerangka kerja unit test biasa (saya menggunakan NUnit).

Sekarang pertanyaan besar. Di mana tepatnya saya harus menarik garis antara tes unit dan tes integrasi? Haruskah saya menguji satu kelas saja (sebanyak mungkin) dengan tes unit? Juga, haruskah pengujian integrasi ditempatkan dalam proyek pengujian yang sama dengan proyek pengujian unit saya?


Tes integrasi melibatkan pengujian lebih dari satu implementasi aktual dari komponen Anda bersama-sama (implementasi aktual berarti tidak ada mengejek).
Kemoda

1
Pertanyaan ini berkaitan dengan pengujian dan QA. Jadi saya akan menyarankan untuk memigrasikannya ke situs terkait, SQA di Stack Exchange ( sqa.stackexchange.com )
dzieciou

@ Dzieciou bahkan tidak tahu itu ada!
Earlz

Jawaban:


19

Integrasi vs. tes unit

Anda harus menjaga tes unit Anda dan tes integrasi Anda sepenuhnya terpisah Unit test Anda harus menguji satu hal dan satu hal saja dan dalam isolasi lengkap dari sisa sistem Anda. Unit didefinisikan secara longgar tetapi biasanya bermuara pada suatu metode atau fungsi.

Masuk akal untuk memiliki tes untuk setiap unit sehingga Anda tahu algoritma mereka diterapkan dengan benar dan Anda segera tahu apa yang salah di mana, jika implementasi cacat.

Karena Anda menguji dalam isolasi lengkap saat pengujian unit, Anda menggunakan objek rintisan dan tiruan untuk berperilaku seperti aplikasi lainnya. Di sinilah tes integrasi masuk. Menguji semua unit dalam isolasi itu bagus tetapi Anda perlu tahu apakah unit tersebut benar-benar bekerja bersama.

Ini berarti mengetahui apakah suatu model benar-benar disimpan dalam database atau jika peringatan benar-benar dikeluarkan setelah algoritma X gagal.

Pengembangan yang digerakkan oleh tes

Mengambil langkah mundur dan melihat Test Driven Development (TDD) ada beberapa hal yang perlu dipertimbangkan.

  1. Anda menulis unit test Anda sebelum Anda benar-benar menulis kode yang membuatnya lulus.
  2. Anda berhasil lulus ujian, tulis kode yang cukup untuk menyelesaikannya.
  3. Sekarang setelah tes berlalu, saatnya untuk mengambil langkah mundur. Apakah ada sesuatu untuk diperbaiki dengan fungsionalitas baru ini? Anda dapat melakukan ini dengan aman karena semuanya tercakup oleh tes.

Integrasi dulu vs Integrasi lalu

Tes integrasi masuk ke dalam siklus TDD ini dalam salah satu dari dua cara. Saya tahu orang-orang yang suka menulisnya sebelumnya. Mereka menyebut tes integrasi tes end-to-end dan mendefinisikan tes ujung ke ujung sebagai tes yang benar-benar menguji seluruh jalur usecase (pikirkan untuk menyiapkan aplikasi, bootstrap, pergi ke controller, menjalankannya, memeriksa hasil, keluaran, dll ...). Kemudian mereka mulai dengan tes unit pertama mereka, membuatnya lulus, menambahkan kedua, membuatnya lulus, dll ... Perlahan-lahan semakin banyak bagian dari lulus uji integrasi juga hingga fitur selesai.

Gaya lainnya adalah membangun uji unit fitur dengan uji unit dan menambahkan tes integrasi yang dianggap perlu sesudahnya. Perbedaan besar antara keduanya adalah bahwa dalam hal uji integrasi terlebih dahulu Anda harus memikirkan desain aplikasi. Jenis ini tidak setuju dengan premis bahwa TDD adalah tentang desain aplikasi dan juga tentang pengujian.

Kepraktisan

Di pekerjaan saya, kami memiliki semua tes kami di proyek yang sama. Namun ada beberapa kelompok berbeda. Alat integrasi berkelanjutan menjalankan apa yang ditandai sebagai unit test terlebih dahulu. Hanya jika yang berhasil adalah pengujian integrasi yang lebih lambat (karena mereka membuat permintaan nyata, menggunakan database nyata, dll) juga dijalankan.

Kami biasanya menggunakan satu file tes untuk satu kelas.

Bacaan yang disarankan

  1. Menumbuhkan perangkat lunak berorientasi objek, dipandu oleh tes-tes Buku ini adalah contoh yang sangat bagus dari metodologi uji integrasi pertama
  2. Seni pengujian unit, dengan contoh di dot.net Pada pengujian unit, dengan contoh di dot.net: D Buku yang sangat bagus tentang prinsip-prinsip di balik pengujian unit.
  3. Robert C. Martin di TDD (Artikel gratis): Bacalah dua artikel pertama yang dia tautkan di sana juga.

2

Apa yang penting dalam setiap strategi pengujian, adalah Cakupan Tes - yaitu mampu menunjukkan bahwa semua fungsionalitas sedang diuji.

Saya umum, dan kecuali Anda memiliki persyaratan khusus yang bertentangan (mis. DO178 Level A, IEC61508 SIL 4 dll) yang tampaknya tidak menjadi kasus dalam situasi Anda, maka jika Anda dapat menguji fungsi penuh dari kelas atau modul (dan menunjukkan bahwa Anda memiliki) pada level sistem, maka pengujian level sistem memadai. Dan seterusnya. Pengujian unit hanya diperlukan bila Anda belum membahas pengujian lebih lanjut.

Di mana tepatnya saya harus menarik garis antara tes unit dan tes integrasi?

Mengingat pengujian integrasi biasanya lebih mudah, lebih cepat dan lebih murah, tarik garis sejauh yang Anda bisa ...

Haruskah saya menguji satu kelas saja (sebanyak mungkin) dengan tes unit?

Tergantung pada ruang lingkup, sekali lagi ... menurut definisi, uji unit menguji satu unit. Tetapi jika Anda dapat sepenuhnya menguji modul penuh dalam sekali jalan, maka jika Anda mau, lakukanlah. Anda sebenarnya memenuhi beberapa tes unit dalam satu pukulan.

Juga, haruskah pengujian integrasi ditempatkan dalam proyek pengujian yang sama dengan proyek pengujian unit saya?

Tidak ada alasan mendasar mengapa tidak ... kecuali pengujian tingkat yang lebih tinggi dilakukan oleh penguji independen, di mana Anda hanya harus mengeluarkan instrumentasi yang dapat dieksekusi dan minimal.


2
Saya gagal melihat bagaimana pengujian integrasi lebih mudah, lebih cepat, atau lebih murah. Bagi saya itu kebalikan dari semua 3. Dan tes integrasi biasanya lebih rapuh daripada tes unit
Earlz

0

Ketika saya memiliki proyek kecil saya hanya memasukkan semua tes ke proyek yang sama. Karena proyek yang lebih besar akan memiliki perpecahan ini saya hanya memastikan bahwa itu mungkin untuk menggoda mereka jika diperlukan.

Dengan tes unit, saya biasanya hanya menguji satu kelas (SUT) dalam file.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.