Tes ujung ke ujung versus tes unit, haruskah tes dipisahkan?


23

Di perusahaan kami, kami biasanya memastikan bahwa kami menulis tes ujung ke ujung untuk situs web / aplikasi web kami. Itu berarti kita mengakses URL, mengisi formulir, mengirimkan formulir ke URL lain dan memeriksa hasil halaman. Kami melakukan ini untuk menguji validasi formulir, menguji bahwa templat HTML memiliki variabel konteks yang benar, dll.

Kami juga menggunakannya untuk secara tidak langsung menguji logika yang mendasarinya.

Saya diberi tahu oleh seorang rekan kerja bahwa alasannya adalah kita dapat merobek dan mengubah implementasi yang mendasarinya pada titik mana pun selama tes ujung ke ujung berlalu.

Saya bertanya-tanya apakah jenis decoupling ini masuk akal atau apakah itu hanya cara untuk menghindari tes menulis untuk unit kode yang lebih kecil?


6
was told by a co-worker that the reason for this is that we can rip out and change the underlying implementation at any point as long as the end-to-end tests pass.- Itu juga berlaku untuk unit test. Bagi saya sepertinya tes ujung ke ujung digunakan sebagai alasan untuk tidak menulis tes unit.
Robert Harvey

12
Itu tidak berlaku untuk unit test. Mengubah / menghapus / membuat metode atau kelas memerlukan memperbarui semua tes unit untuk metode atau kelas tersebut. Tidak demikian dalam tes ujung ke ujung kecuali fungsi pengguna akhir berubah. Selama itu adalah refactor tingkat sistem (tidak ada modifikasi fungsi pengguna akhir) tidak diperlukan perubahan pada tes ujung ke ujung.
dietbuddha

2
@ Dietbuddha, saya pikir konsep umum berlaku untuk unit test, tetapi pada lingkup (unit) yang lebih kecil.
Sam

Jawaban:


38

Tes end-to-end juga diperlukan. Bagaimana lagi Anda bisa tahu Anda menghubungkan semua unit dengan benar? Pada kode yang sangat sederhana, adalah mungkin untuk menguji semua jalur melalui kode hanya dengan tes ujung ke ujung, tetapi ketika Anda mendapatkan lebih banyak lapisan, menjadi sangat mahal untuk melakukannya.

Misalnya, Anda memiliki tiga lapisan, masing-masing dengan lima jalur yang memungkinkan. Untuk menguji semua jalur melalui seluruh aplikasi akan membutuhkan 5 3 tes ujung ke ujung, tetapi Anda dapat menguji semua jalur melalui setiap unit dengan hanya 5 · 3 unit tes. Jika Anda hanya melakukan pengujian end-to-end, banyak jalur berakhir diabaikan, sebagian besar dalam penanganan kesalahan dan kondisi batas.


Itu jawaban yang bagus. Saya melihat nilai keduanya tetapi melihat sejumlah kemungkinan untuk sepenuhnya menguji semua jalur dengan tes ujung ke ujung sangat membantu untuk menjelaskan mengapa pengujian unit perlu dilakukan lebih dari itu
Rudolf Olah

14
Saya melihat unit test berharga karena sebagian besar karena mereka melokalisasi masalah dengan cepat. End-to-end berharga karena memberi Anda keyakinan bahwa semuanya bekerja bersama.
Jason Swett

20

Ya, tes ujung ke ujung (atau tes integrasi) sangat masuk akal, tetapi begitu juga dengan tes unit. Idealnya, Anda memiliki keduanya, karena keduanya biasanya menangkap berbagai jenis bug. Dengan demikian, melakukan tes ujung ke ujung tidak boleh menjadi alasan untuk tidak melakukan tes unit.


2
Catatan singkat tentang kata-kata; walaupun bukan ilmu pasti, banyak orang akan mengatakan bahwa tes end-to-end dan tes integrasi adalah hal yang berbeda. Lihat stackoverflow.com/questions/4904096/…
sbrattla

6

Setelah beberapa tahun coding dan mengerjakan proyek saya akan memberikan jawaban untuk pertanyaan saya sendiri.

Ya, Anda harus menulis unit test. Tes ujung ke ujung lebih sulit untuk ditulis dan rapuh terutama jika mereka mengandalkan komponen UI.

Jika Anda menggunakan kerangka kerja seperti Django atau Rails (atau kelas kustom Anda sendiri), Anda harus memiliki kelas formulir yang akan menangani validasi formulir. Anda juga akan melihat kelas yang menampilkan templat yang diberikan dan formulir serta menangani permintaan GET dan POST.

Dalam tes ujung ke ujung Anda akan:

  1. dapatkan url
  2. isi formulir dengan data yang valid
  3. poskan formulir ke url
  4. periksa untuk memastikan bahwa basis data telah diperbarui atau beberapa tindakan telah dilakukan sebagai hasil dari formulir yang valid

Anda menguji banyak kode dan cakupan Anda akan cukup bagus, tetapi Anda hanya menguji jalur bahagia ketika semuanya berjalan dengan baik. Bagaimana Anda memastikan bahwa formulir memiliki validasi yang benar di dalamnya? Bagaimana jika formulir itu digunakan pada banyak halaman? Apakah Anda menulis tes ujung ke ujung lagi?

Mari kita coba ini lagi dengan unit test:

  1. menguji metode tampilan GET
  2. uji metode tampilan POST dengan formulir palsu / tiruan
  3. uji formulir dengan data yang valid
  4. uji formulir dengan data yang tidak valid
  5. uji efek samping formulir

Dengan menggunakan tes unit, Anda menguji potongan kode yang lebih kecil dan tes khusus dan lebih mudah untuk ditulis. Ketika Anda menggabungkan ini dengan TDD (Test Driven Development) Anda mendapatkan kode kualitas yang lebih tinggi.

Kemudahan penulisan unit test tidak boleh diabaikan karena ketika Anda berada di proyek yang tidak memiliki pengujian otomatis, Anda harus memulai suatu tempat. Memulai dengan unit test lebih mudah dan lebih cepat dan memungkinkan Anda segera mulai menguji bug daripada hanya untuk jalur senang.


titik data lain, Google Testing Blog mengatakan tidak untuk lebih banyak tes end2end
Rudolf Olah

5

Sebenarnya tes end-to-end, atau tes integrasi lebih penting daripada tes unit karena mereka memastikan bahwa Anda memiliki sistem yang berfungsi penuh. Tes unit tidak mencakup bagian integrasi sistem, yang merupakan tugas yang rumit terutama dalam proyek-proyek besar.

Namun seperti yang telah dikatakan, Anda harus melakukan pengujian unit juga, karena lebih rumit untuk menangkap kasus tepi dalam pengujian integrasi.


1

Ini memverifikasi perilaku sistem, sedangkan tes unit memverifikasi perilaku unit. Manfaat dan biaya untuk masing-masing berbeda. Anda bisa melakukan satu atau yang lain atau keduanya.

Di pekerjaan saya, kami melakukan Acceptance Test Driven Development tanpa unit test yang terdengar mirip dengan yang telah Anda jelaskan. Kami mulai melakukan keduanya dan seiring waktu, akhirnya menghilangkan pengujian unit untuk biaya melebihi manfaat bagi kami.

Karena itu saya pikir biaya / manfaat untuk domain masalah dan lingkungan Anda harus mendorong keputusan untuk terlibat dalam praktik pengembangan apa pun, termasuk berbagai praktik pengujian otomatis. Daripada beriman, saya lebih suka semua praktik memiliki bukti empiris dalam konteks yang digunakan untuk mendukungnya.


Yang saya khawatirkan adalah bahwa kita akan mengkodekan terhadap tes penerimaan yang mengarah ke kelas atau metode besar alih-alih unit yang lebih kecil.
Rudolf Olah

@ Home: Hanya karena Anda tidak menulis unit test, tidak ada alasan untuk tidak menulis kode yang baik. Namun, jika Anda memiliki programmer yang tidak berpengalaman atau hanya memiliki kebiasaan buruk maka manfaatnya mungkin lebih besar daripada biayanya. Dalam kedua kasus Anda harus melakukan analisis dan menguranginya menjadi persamaan sederhana. For Any Practice: Practice iff Benefit > Cost
dietbuddha
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.