Bagaimana Anda dapat TDD untuk bug yang hanya dapat diuji setelah diperbaiki?


13

Ini salah satu contohnya: Aplikasi web saya mengandung elemen yang dapat diseret. Saat menyeret elemen, browser menghasilkan "gambar hantu". Saya ingin menghapus "gambar hantu" ketika menyeret dan saya menulis tes untuk perilaku ini.

Masalah saya adalah bahwa saya awalnya tidak tahu cara memperbaiki bug ini dan satu-satunya cara saya bisa menulis tes adalah setelah saya memperbaikinya.

Dalam fungsi sederhana seperti let sum = (a, b) => a - b, Anda dapat menulis tes mengapa sum(1, 2)tidak sama 3sebelum menulis kode apa pun.

Dalam kasus yang saya jelaskan, saya tidak dapat menguji, karena saya tidak tahu apa verifikasi itu (saya tidak tahu apa yang seharusnya menjadi pernyataan).

Solusi untuk masalah yang dijelaskan adalah:

let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';

document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);

Saya tidak mungkin tahu bahwa ini adalah solusinya. Saya bahkan tidak bisa menulis tes setelah menemukan solusi online, karena satu-satunya cara saya bisa tahu jika itu benar-benar bekerja, adalah menambahkan kode ini ke dalam basis kode saya dan memverifikasi dengan browser jika memiliki efek yang diinginkan. Tes harus ditulis setelah kode, yang bertentangan dengan TDD.

Apa yang akan menjadi pendekatan TDD untuk masalah ini? Apakah menulis tes sebelum kode wajib atau opsional?


2
Lakukan penelitian Anda kemudian. Temukan solusinya ... kemudian tulis pengujian, perbaikan, dan refactor Anda. Pengujian tidak dimaksudkan untuk (hanya) memverifikasi bahwa kode Anda berfungsi, tetapi sebagai bukti di masa depan solusi lengkap Anda. Awalnya Anda membuat pengujian gagal, properti apa yang akan Anda uji? Itu salah satu cara untuk memulai.
Juan Carlos Eduardo Romaina Ac

@Kilian Foth: Saya melihat niat baik Anda dengan mengubah judul pertanyaan, tetapi hasil edit Anda membatalkan jawaban saya. Selain itu, judul baru Anda tidak sesuai dengan badan pertanyaan. Jadi saya melakukan rollback, jangan tersinggung.
Doc Brown

Jawaban:


26

Ketika saya memahami Anda dengan benar, Anda bahkan tidak dapat menulis tes otomatis yang dapat diandalkan untuk contoh "gambar hantu" Anda setelah Anda menemukan solusi, karena satu-satunya cara memverifikasi perilaku yang benar adalah dengan melihat layar dan memeriksa apakah tidak ada gambar hantu lagi. Itu memberi saya kesan headline asli Anda menanyakan pertanyaan yang salah. Pertanyaan sebenarnya seharusnya

  • bagaimana cara secara otomatis menguji perilaku tertentu dari antarmuka pengguna grafis?

Dan jawabannya adalah - untuk beberapa jenis masalah UI, Anda tidak . Tentu saja, seseorang dapat mencoba untuk mengotomatiskan membuat UI menunjukkan masalah, dan mencoba untuk mengimplementasikan sesuatu seperti perbandingan tangkapan layar, tetapi ini sering rawan kesalahan, rapuh dan tidak hemat biaya.

Terutama desain "test driving" UI atau peningkatan UI oleh tes otomatis yang ditulis di muka secara harfiah tidak mungkin. Anda "mengarahkan" desain UI dengan melakukan peningkatan, menunjukkan hasilnya kepada manusia (diri Anda sendiri, beberapa penguji atau pengguna) dan meminta umpan balik.

Jadi terima fakta bahwa TDD bukan peluru perak, dan untuk beberapa jenis masalah masih pengujian manual lebih masuk akal daripada tes otomatis. Jika Anda memiliki proses pengujian yang sistematis, mungkin dengan beberapa penguji yang berdedikasi, hal terbaik yang dapat Anda lakukan adalah menambahkan kasing pada rencana pengujian mereka.


Secara umum pengujian UI bersifat non-sepele; Anda dapat menyematkan hash gambar yang dihasilkan, Anda dapat mensimulasikan / mengotomatisasi, Anda dapat merekam makro, Anda dapat menggunakan solusi berpemilik, Anda dapat menggunakan pengujian manual, tergantung pada situasi dan seberapa diperlukan pengujian UI otomatis untuk proyek Anda.
esoterik

1
@ Esoterik: ya, dan semua teknik otomatis ini rawan kesalahan dan rapuh, seperti yang sudah saya tulis. Satu-satunya pendekatan non-rapuh yang saya tahu adalah pengujian manual.
Doc Brown

3
Terimakasih telah menjawab. Saya pikir Anda benar, saya keliru berharap menemukan peluru perak di TDD. Tampaknya tidak ada cara yang efisien untuk menguji apa yang ingin saya uji - perbandingan tangkapan layar dan semua yang di atas tampaknya tidak memberikan ROI yang cukup. Perbandingan tangkapan layar khususnya tampaknya sangat memakan waktu dan, seperti yang Anda katakan, rawan kesalahan.
maximedupre

1
@maximedupre: menemukan iklan ini untuk alat yang mencoba mengatasi masalah tersebut, tetapi artikel tersebut sepertinya setuju dengan jawaban saya secara umum.
Doc Brown

5

Apa yang akan menjadi pendekatan TDD untuk masalah ini? Apakah menulis tes sebelum kode wajib atau opsional?

Salah satu caranya adalah menerapkan analog dari solusi spike .

James Shore menggambarkannya seperti ini:

Kami melakukan eksperimen kecil dan terisolasi ketika kami membutuhkan informasi lebih lanjut.

Ide dasarnya adalah bahwa Anda meletakkan alat desain saat Anda mencari tahu apa yang sedang terjadi. Setelah memiliki bantalan Anda, Anda mengambil alat desain lagi.

Caranya: Anda membawa pengetahuan dari penyelidikan Anda kembali ke basis kode produksi Anda, tetapi Anda tidak membawa kode itu . Alih-alih, Anda membuatnya ulang saat menggunakan teknik desain disiplin.

Kuda untuk kursus.

EDIT:

Bagaimana Anda mengotomatiskan tes jika cacat hanya dapat dilihat oleh mata manusia?

Saya ingin menyarankan ejaan yang sedikit berbeda: "Bagaimana Anda bisa mengotomatiskan tes jika mengotomatisasi tes tidak efektif biaya?"

Jawabannya, tentu saja, "Anda tidak". Alih-alih, cobalah untuk memisahkan implementasi Anda menjadi dua bagian - sebagian besar di mana pengujian efektif biaya, dan bagian yang lebih kecil yang terlalu mudah untuk dipecah.

Ada dua cara membangun desain perangkat lunak: Salah satu caranya adalah membuatnya sangat sederhana sehingga jelas tidak ada kekurangan - CAR Hoare

Jadi ketika bekerja dengan kode pihak ketiga, kami akan memiliki shell kode yang sangat tipis yang bertindak sebagai proxy untuk perpustakaan pihak ketiga. Dalam pengujian, kami mengganti shell itu dengan "test double", yang memverifikasi protokol , tanpa khawatir akan menghasilkan efek yang diinginkan.

Untuk pengujian integrasi kode kami dengan kode pihak ketiga nyata, kami mengandalkan teknik lain (verifikasi visual, panggilan dukungan teknis, optimisme ....)

Berguna untuk menyimpan beberapa artefak demonstrasi di sekitar, sehingga Anda dapat memeriksa bahwa asumsi Anda masih berlaku ketika Anda meningkatkan perpustakaan pihak ketiga.


Saya suka apa yang dikatakan James Shore. Saat ini saya mengikuti screencast www.letscodejavascript.com dan saya banyak belajar. Saya akan membaca tautan yang Anda tunjuk.
maximedupre

Anda benar, saya membaca lebih lanjut tentang TDD dan paku. Anda sebenarnya perlu tahu bagaimana kode yang Anda coba periksa terlihat sebelum mencoba mengujinya. TDD tidak bisa mengajari Anda apa pun yang belum Anda ketahui, tetapi berpotensi menunjukkan kepada Anda beberapa hal yang perlu Anda pelajari, memparafrasekan James Shore. Pada catatan itu, saya ingin mengusulkan langkah tambahan di TDD: Spike, Test, Fail, Pass, Refactor.
maximedupre

0

Perspektif yang berbeda, pengujian di sekitar UI / GUI dapat dilakukan agak lebih baik dalam hal pengujian penerimaan (fitur / tes yang berpusat pada alur kerja bisnis).

Untuk web, saya pikir kerangka kerja seperti selenium webdriver memiliki potensi untuk mendekati tes yang benar, tetapi overhead untuk memulai bisa sedikit banyak, dan itu adalah perubahan dalam aliran yang terlihat dengan TDD sehubungan dengan hanya unit test .

Bagian yang secara khusus akan membantu situasi Anda adalah sesuatu yang disebut Page Object Model ( https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html ). Ini mencapai pemetaan eksplisit run-time GUI ke beberapa kode, baik dengan penamaan metode / acara / anggota kelas.

Argumen utama yang menentang hal ini adalah overhead, dan bahwa overhead ini biasanya dapat dilihat pada akhir siklus pengembangan. Overhead adalah bahwa tes memerlukan beberapa pembungkus yang akan muncul untuk membuat pekerjaan yang digandakan.

Ke depan, itu akan tergantung pada biaya / manfaat tim dan bisnis, jadi itu bisa menjadi topik yang bermanfaat untuk dibahas untuk menentukan harapan dan pandangan.


Saya benar-benar mencoba e2e / tes fungsional (dengan selenium webdriver) di TDD baru-baru ini, tetapi biaya overhead pasti terlalu besar seperti yang Anda katakan. Anda tidak bisa menjadi pengembang yang efisien dan melakukan TDD dengan tes e2e. Saya menggunakan POM, tetapi satu-satunya manfaat yang diberikannya adalah peningkatan arsitektur dalam basis kode pengujian saya.
maximedupre

Ya, saya pikir pilihan yang lebih layak yang telah saya lihat dari perusahaan yang berbeda untuk tim yang berbeda adalah untuk memasukkan proses SQA yang lebih manual, di mana anggota tim / tim ditunjuk untuk hanya melakukan preform tes manual dari UI. Sebagian besar tes memiliki tangkapan layar dan dokumentasi langkah demi langkah. Paling tidak, sesuatu seperti itu akan menghasilkan beberapa bukti pengujian terhadap suatu aplikasi.
eparham7861

0

Seperti apa rupa gambar hantu? Jika Anda membuat boneka ui dengan satu warna yang dikenal, di mana Anda meletakkan komponen yang dapat diseret? Apakah akan ada hadiah warna tertentu jika ada gambar hantu.

Kemudian tes bisa menguji tidak adanya warna gambar hantu.

Tes semacam itu akan masuk akal, tahan lama, dan bisa dilakukan.


Dapat dilakukan - ya. Tahan lama - tergantung. Hanya mengubah warna / tema UI Anda dapat merusak tes Anda, itu kedengarannya tidak terlalu tahan lama bagi saya.
Sean Burton

1
Anda tidak akan menguji keseluruhan UI Anda. Anda akan membuat dummy ui untuk komponen drag-n-drop.
Esben Skov Pedersen

Saya tidak yakin bagaimana mencapai apa yang Anda sarankan. Gambar hantu dalam kasus saya akan menjadi replika semi-buram dari elemen yang sedang diseret. Gambar hantu mengikuti kursor sepanjang waktu saat seret dan lepas terjadi.
maximedupre

Iya. Anda harus mengotomatiskan penyeret. Itu tidak akan menjadi unit test melainkan tes e2e.
Esben Skov Pedersen
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.