Ini adalah utas yang bagus, dan saya sangat menyukai Jawaban dari @KAndy dan @fschmengler.
Saya ingin menambahkan beberapa pemikiran tambahan yang saya anggap berharga ketika mengajukan pertanyaan seperti "Haruskah saya menguji X?" atau "Bagaimana saya harus menguji X?".
Apa yang bisa salah?
- Saya bisa membuat kesalahan ketik bodoh (terjadi sepanjang waktu)
Ini biasanya tidak membenarkan menulis tes.
- Apakah saya akan menyalin kode yang saya butuhkan dari inti atau modul yang berbeda, dan kemudian menyesuaikannya dengan kebutuhan saya?
Saya menemukan ini sebenarnya hal yang sangat berbahaya untuk dilakukan yang sering meninggalkan bug halus. Dalam hal ini, saya lebih suka menulis tes, jika tidak terlalu mahal. Membuat konfigurasi model sumber berdasarkan sebenarnya akan membuat mereka lebih berisiko IMO.
- Bisakah ada konflik dengan modul yang berbeda?
Ini hampir hanya berlaku untuk kode konfigurasi. Dalam kasus seperti itu saya ingin memiliki tes integrasi yang memberi tahu saya ketika itu terjadi.
- Bisakah Magento mengubah API dalam rilis yang akan datang?
Sangat tidak mungkin dalam hal ini, karena kode Anda hanya bergantung pada antarmuka. Tetapi semakin banyak kelas konkret yang terlibat atau jika kode saya memperluas kelas inti, ini menjadi risiko yang lebih potensial.
- Versi PHP baru dapat memecahkan kode saya. Atau mungkin saya ingin mendukung PHP 5.6 untuk tahun-tahun mendatang.
Sekali lagi, sangat tidak mungkin di sini, tetapi dalam beberapa kasus saya ingin tes memperingatkan saya, haruskah saya mengubah kode di masa depan untuk menggunakan sintaks yang tidak kompatibel.
Seberapa mahal untuk menguji kode?
Ini memiliki dua aspek:
- Jumlah usaha dan waktu yang dibutuhkan untuk menulis ujian
- Jumlah usaha dan waktu yang diperlukan untuk menguji potongan kode yang akan saya tulis secara manual.
Selama pengembangan beberapa kode, saya cenderung harus menjalankan kode yang saya tulis cukup sering sampai saya menganggapnya selesai. Ini tentu saja jauh lebih mudah dengan uji unit.
Dalam kasus Anda, menulis ujian sangat murah. Tidak butuh banyak waktu atau usaha. @KAndy benar bahwa semua kode perlu dipertahankan, tetapi sekali lagi, tidak semua tes perlu disimpan.
Ini mungkin contoh di mana saya akan menulis unit test, hanya untuk memeriksa saya tidak membuat kesalahan bodoh, dan kemudian menghapusnya setelah kelas selesai. Jika tes tidak memberikan nilai jangka panjang, saya pikir menghapusnya masuk akal.
Pertanyaan ini juga penting dalam hal memilih jenis tes untuk ditulis: unit atau integrasi misalnya.
Seberapa berharganya potongan kode yang saya tulis?
Jika sepotong kode yang saya tulis sangat penting untuk layanan yang disediakan modul, saya mengujinya, terlepas dari seberapa sepele itu.
Jika itu hanya metode utilitas kecil, misalnya UI fokus, dan bukan bagian dari logika bisnis, maka mungkin tidak.
Apakah kode perlu diubah?
Seiring waktu, saya menjadi sangat terbiasa memiliki cakupan pengujian, sehingga mengubah kode yang terbuka terasa sangat tidak aman. Itu termasuk hal-hal yang sangat sederhana seperti menambahkan opsi ke model sumber, tetapi juga hal-hal seperti memindahkan kelas ke folder / namespace yang berbeda, atau mengubah nama metode.
Memiliki tes untuk perubahan tersebut sangat berharga.
Apakah perlu dokumentasi?
Seberapa sulit untuk menggunakan kode? Dalam contoh Anda itu sepele, tetapi dalam beberapa kasus yang lebih kompleks, melakukan tes sangat bagus untuk keperluan dokumentasi untuk pengembang lain (atau saya sendiri dalam beberapa bulan).
Eksplorasi dan Pembelajaran
Jika saya mengerjakan beberapa kode dan saya tidak yakin cara mengujinya, saya merasa sangat berharga untuk menulis tes. Prosesnya hampir selalu memberi saya pemahaman yang lebih dalam tentang apa yang saya hadapi.
Ini terutama berlaku untuk pengembang yang masih menganggap diri mereka sedang belajar pengujian.
Ini juga merupakan contoh di mana mungkin masuk akal untuk menghapus tes setelahnya, karena nilai utama yang diberikannya adalah belajar.
Disiplin dan Stres
Menempel pada loop merah-hijau-refactor membantu saya untuk bergerak cepat. Ini terutama benar di bawah tekanan. Jadi, bahkan jika beberapa bagian kode tidak benar-benar layak uji, saya mungkin masih mengikuti TDD, terutama jika kode itu sepele untuk diuji.
Ini membuat saya dalam arus dan waspada.
Apa dan bagaimana cara menguji?
Juga pertimbangkan Anda dapat menulis tes dalam rincian yang sangat berbeda.
- Menguji nilai pengembalian tepat.
Ini akan menjadi tes yang sangat kaku yang harus disesuaikan dengan setiap perubahan. Apakah Anda ingin tes untuk istirahat, misalnya, jika urutan item dalam array kembali berubah?
- Menguji struktur nilai pengembalian.
Untuk model sumber ini bisa memeriksa setiap sub-array sebagai dua catatan, satu dengan a label
dan satu dengan value
kunci.
- Memeriksa implementasi kelas
ArrayInterface
.
- Menguji kelas menyediakan
getOptions()
meskipun metode itu bukan bagian dari antarmuka yang diimplementasikan.
Untuk setiap hal yang mungkin dapat diuji, pertimbangkan nilai, rawatan, dan biaya.
Ringkasan
Singkatnya: tidak ada jawaban tunggal sejati untuk sebuah pertanyaan jika beberapa kode harus diuji atau tidak. Jawabannya akan berbeda untuk setiap pengembang tergantung pada keadaan.