Bagaimana orang-orang mempertahankan ruang tes mereka?

Secara khusus, saya ingin tahu tentang aspek-aspek berikut:

1. Bagaimana Anda tahu bahwa kasus pengujian Anda salah (atau kedaluwarsa) dan perlu diperbaiki (atau dibuang)? Maksud saya, bahkan jika suatu test case menjadi tidak valid, itu mungkin masih berlalu dan tetap diam, yang dapat membuat Anda secara salah percaya bahwa perangkat lunak Anda bekerja dengan baik. Jadi, bagaimana Anda menyadari masalah seperti pada test suite Anda?

2. Bagaimana Anda tahu bahwa test suite Anda tidak lagi memadai dan bahwa test case baru harus ditambahkan? Saya kira ini ada hubungannya dengan perubahan persyaratan, tetapi apakah ada pendekatan sistematis untuk memeriksa kecukupan test suite?

Jawaban singkat: gunakan alat yang dikenal yang membantu menjaga kualitas kasus uji seperti cakupan kode berikut dan alat kualitas kode: Cobertura, PMD, Sonar, dll. Yang akan membantu Anda memperhatikan ketika komponen penting dari program tidak cukup diuji. Juga, tulis tes integrasi, yang kemungkinan besar akan rusak lebih dulu setiap kali terjadi kesalahan.

Jawaban panjang:

Bagaimana Anda tahu bahwa kasus pengujian Anda salah (atau kedaluwarsa) dan perlu diperbaiki (atau dibuang)? Maksud saya, bahkan jika suatu test case menjadi tidak valid, itu mungkin masih berlalu dan tetap diam, yang dapat membuat Anda secara salah percaya bahwa perangkat lunak Anda bekerja dengan baik. Jadi, bagaimana Anda menyadari masalah seperti pada test suite Anda?

• Menggunakan alat cakupan kode seperti Cobertura , Anda dapat mendeteksi bahwa kasus uji untuk kelas tertentu, atau metode kompleks, tidak lagi memadai. Anda tidak perlu mencapai cakupan kode 100% di mana-mana dan dalam kebanyakan kasus akan sulit untuk dicapai dan belum tentu berguna; tetapi tes untuk aspek paling kritis dari suatu program harus dipertahankan dengan tujuan setidaknya 80% dari cakupan kode.
• Menggunakan alat membangun dan integrasi berkelanjutan , seperti Jenkins yang sangat saya sukai, dalam kombinasi dengan plugin Sonar , Anda dapat mengatur pemicu yang mengirim email dan jenis peringatan lainnya kepada orang yang bertanggung jawab atas perubahan terbaru. Berbagai grafik dan statistik (Sonar juga menggunakan Cobertura di antara banyak alat lain) membantu peninjau kode dan pengembang uji kasus untuk fokus pada apa yang penting.

Bagaimana Anda tahu bahwa test suite Anda tidak lagi memadai dan bahwa test case baru harus ditambahkan? Saya kira ini ada hubungannya dengan perubahan persyaratan, tetapi apakah ada pendekatan sistematis untuk memeriksa kecukupan test suite?

Apa yang saya tulis untuk pertanyaan pertama adalah bagian dari jawaban untuk pertanyaan kedua Anda. Saya juga akan menambahkan poin-poin berikut di sini:

• Tulis kasus uji integrasi (atau kasus "bisnis" jika Anda mau) sebagai tambahan dari kasus uji. Ini kemungkinan besar akan berubah / rusak terlebih dahulu karena mereka sering bergantung pada beberapa kelas / metode. Dan karena mereka sering pecah, kecil kemungkinannya akan dilupakan. Satu-satunya pendekatan / metodologi yang, dari pengalaman pribadi saya, membantu menulis tes yang baik adalah Test-Driven Development . Terutama jika orang yang menulis test case BUKAN orang yang sama menulis kode untuk itu. Menulis kasus uji yang baik menggunakan TDD juga membutuhkan waktu, tetapi hasilnya, setidaknya bagi saya, sangat memuaskan.
• Setiap kali bug keluar, tulis perbaikannya dan test case yang menyertainya. Kasing uji hanya akan mencakup bug khusus ini. Karena Anda telah sepenuhnya menutupi kode yang bertanggung jawab atas bug, itu tidak akan keluar lagi.

Sebenarnya tidak ada cara untuk memastikan kasus pengujian Anda benar, kecuali dengan berkonsentrasi dengan sangat baik saat membuatnya - memahami persyaratan, memahami kode, dan memastikan bahwa mereka setuju. Intinya memiliki test suite adalah Anda hanya perlu melakukan ini sekali saja, dan sejak saat itu Anda dapat menjalankan kembali tes dan memastikan bahwa tes tersebut lulus, sedangkan tanpa test suite Anda harus berkonsentrasi sangat keras setiap saat. , yaitu setiap kali Anda melakukan sesuatu pada basis kode Anda. Tetapi masalah mendasar karena harus memastikan bahwa Anda melakukan hal yang benar tetap ada - komputer memang tidak cukup cerdas untuk membebaskan kita dari tugas itu.

Karena itu, (1) jika ruang tes Anda tidak lengkap, tidak ada cara sederhana untuk melihatnya. Analisis cakupan kode dapat membuktikan bahwa beberapa baris kode tidak pernah dieksekusi, yaitu bahwa suite kekurangan dalam beberapa hal, tetapi tidak seberapa parah kekurangan itu, dan tidak pernah dapat membuktikan bahwa itu cukup. Bahkan dengan cakupan kode 100% Anda tidak memiliki jaminan bahwa semua negara yang relevandari sistem dilaksanakan, dan cakupan negara lengkap tidak dapat dicapai untuk sistem realistis karena jumlah kombinasi dari negara yang bisa ada. Salah satu teknik yang baik untuk memastikan bahwa Anda menguji kasus setidaknya benar untuk memeriksa hal yang ingin Anda periksa adalah menulis tes, memverifikasi bahwa itu memang gagal, menulis / mengubah kode, dan kemudian memverifikasi bahwa itu sudah lewat. Karena itu, antusiasme untuk pengembangan yang digerakkan oleh tes: tes ini memungkinkan Anda untuk cukup yakin bahwa tes individu melakukan hal yang benar, dan jika Anda membuat seluruh basis kode Anda dengan cara itu, Anda bisa mendapatkan tingkat kepercayaan yang serupa bahkan dalam sistem yang besar.

(2) Paket uji biasanya menjadi tidak memadai setiap kali persyaratan berubah - Anda tidak perlu menebak. Jika pelanggan menginginkan beberapa perilaku tertentu diubah, dan pengujian Anda akan berhasil sebelum dan sesudah perubahan, maka jelas mereka tidak menggunakan hubungan input / output tertentu.

Mengenai sistem warisan yang tidak memiliki cakupan tes, atau di mana Anda tidak tahu apa cakupannya, tidak ada bukti formal, tetapi (penasehat orang tua: pendapat pribadi mengikuti!) Berbicara dari pengalaman, sangat mungkin bahwa tes yang tidak memadai. Ketika pengujian dipandang sebagai aktivitas setelah-fakta-opsional, opsional, peningkatan kualitas-tetapi-tidak-benar-benar-diperlukan, itu cenderung tidak lengkap dan tidak sistematis karena insentif untuk memastikan tes mengikuti kode dasar hanya tidak di sana.