Semuanya memiliki antarmuka. Ketika saya mengenakan topi pengujian saya, saya menggunakan pandangan dunia tertentu untuk menulis tes:
- Jika ada sesuatu, itu bisa diukur.
- Jika tidak bisa diukur, itu tidak masalah. Jika itu penting, saya belum menemukan cara untuk mengukurnya.
- Persyaratan menentukan sifat yang terukur, atau tidak berguna.
- Suatu sistem memenuhi persyaratan ketika transisi dari keadaan yang tidak diharapkan ke keadaan yang diharapkan ditentukan oleh persyaratan.
- Suatu sistem terdiri dari komponen yang berinteraksi, yang mungkin merupakan subsistem. Suatu sistem benar ketika semua komponen benar dan interaksi antara komponen benar.
Dalam kasus Anda, sistem Anda memiliki tiga bagian utama:
- beberapa jenis data atau gambar, yang dapat diinisialisasi dari file
- mekanisme untuk menampilkan data
- mekanisme untuk memodifikasi data
Kebetulan, itu terdengar sangat mirip dengan arsitektur Model-View-Controller asli bagi saya. Idealnya, ketiga elemen ini menunjukkan kopling longgar - yaitu, Anda mendefinisikan batas yang jelas di antara mereka dengan antarmuka yang terdefinisi dengan baik (dan karenanya dapat diuji dengan baik).
Interaksi yang kompleks dengan perangkat lunak dapat diterjemahkan ke dalam langkah-langkah kecil yang dapat diutarakan dalam hal elemen-elemen sistem yang kami uji. Sebagai contoh:
Saya memuat file dengan beberapa data. Ini menampilkan grafik. Ketika saya menyeret slider di UI, grafik menjadi semua goyah.
Ini tampaknya mudah untuk diuji secara manual dan sulit untuk menguji otomatis. Tapi mari terjemahkan cerita itu ke dalam sistem kami:
- UI menyediakan mekanisme untuk membuka file: Pengendali sudah benar.
- Ketika saya membuka file, Controller mengeluarkan perintah yang sesuai untuk Model: interaksi Controller-Model sudah benar.
- Diberikan file uji, model mem-parsing ini ke dalam struktur data yang diharapkan: Model sudah benar.
- Diberikan struktur data uji, tampilan membuat output yang diharapkan: tampilan benar. Beberapa struktur data tes akan menjadi grafik normal, yang lain akan menjadi grafik goyah.
- Tampilan interaksi – Model sudah benar
- UI menyediakan slider untuk membuat grafik goyah: Pengontrol sudah benar.
- Ketika slider diatur ke nilai tertentu, Controller mengeluarkan perintah yang diharapkan untuk Model: interaksi Controller-Model sudah benar.
- Ketika menerima perintah uji tentang kegoyahan, Model mengubah struktur data uji menjadi struktur data hasil yang diharapkan.
Dikelompokkan berdasarkan komponen, kami berakhir dengan properti berikut untuk diuji:
- Model:
- mem-parsing file
- menanggapi perintah buka file
- menyediakan akses ke data
- menanggapi perintah make-wobbly
- Melihat:
- Pengendali:
- menyediakan alur kerja file-terbuka
- mengeluarkan perintah buka file
- menyediakan alur kerja make-wobbly
- masalah perintah make-goyah
- sistem keseluruhan:
- koneksi antara komponen sudah benar.
Jika kita tidak menguraikan masalah pengujian menjadi subtitle yang lebih kecil, pengujian menjadi sangat sulit, dan benar-benar rapuh. Cerita di atas juga dapat diimplementasikan sebagai "ketika saya memuat file tertentu dan mengatur slider ke nilai tertentu, gambar tertentu akan ditampilkan". Ini rapuh karena rusak ketika elemen apa pun dalam sistem berubah.
- Itu rusak ketika saya mengubah kontrol untuk kegoyahan (misalnya menangani pada grafik, bukan slider di panel kontrol).
- Itu rusak ketika saya mengubah format output (misalnya bitmap yang diberikan berbeda karena saya mengubah warna default grafik, atau karena saya menambahkan anti-aliasing untuk membuat grafik terlihat lebih halus. Perhatikan bahwa dalam kedua kasus ini).
Tes granular juga memiliki keuntungan yang sangat besar sehingga memungkinkan saya untuk mengembangkan sistem tanpa takut merusak fitur apa pun. Karena semua perilaku yang diperlukan diukur dengan test suite lengkap, tes akan memberi tahu saya jika ada yang rusak. Karena mereka granular, mereka akan mengarahkan saya ke area masalah. Misalnya jika saya secara tidak sengaja mengubah antarmuka komponen apa pun, hanya pengujian antarmuka yang akan gagal dan bukan tes lain yang terjadi secara tidak langsung menggunakan antarmuka itu.
Jika pengujian seharusnya mudah, ini membutuhkan desain yang sesuai. Misalnya, bermasalah ketika saya memasang komponen dalam suatu sistem: jika saya ingin menguji interaksi komponen dengan komponen lain dalam suatu sistem, saya perlu mengganti komponen-komponen lain dengan stub uji yang memungkinkan saya masuk, memverifikasi, dan koreografi interaksi itu. Dengan kata lain, saya memerlukan mekanisme injeksi dependensi, dan dependensi statis harus dihindari. Saat menguji UI, ini sangat membantu ketika UI ini bisa skrip.
Tentu saja, sebagian besar dari itu hanyalah fantasi dunia yang ideal di mana segala sesuatunya dipisahkan dan mudah diuji dan terbang unicorn menyebarkan cinta dan kedamaian ;-) Meskipun ada sesuatu yang secara fundamental dapat diuji, seringkali sangat sulit untuk melakukannya, dan Anda harus lebih baik menggunakan waktu Anda. Namun, sistem dapat direkayasa untuk dapat diuji, dan biasanya sistem pengujian-agnostik fitur internal API atau kontrak yang dapat diuji (jika tidak, saya yakin arsitektur Anda adalah omong kosong dan Anda telah menulis bola besar lumpur). Dalam pengalaman saya, bahkan sejumlah kecil pengujian (otomatis) mempengaruhi peningkatan kualitas yang nyata.
