Spesifikasi penulisan - pernyataan atau hipotesis pengujian - biasanya dilewati dalam kursus TDD karena hanya ada sedikit pemrograman.
Namun, mereka sangat penting.
Mereka menentukan bagaimana dan tes apa yang akan ditulis, dan juga menentukan betapa mudahnya untuk memperbaiki kerusakan. Mereka hampir tidak memerlukan waktu untuk implementasi. Mereka adalah yang pertama yang menghubungkan pengguna cerita dan kode dan yang pertama yang menunjukkan kegagalan kode tes. Mereka juga yang melindungi kita dari kesalahan dalam kode tes itu sendiri.
Bagaimana kita bisa membuat pernyataan kita lebih baik?
Pertama,
spesifikasinya harus terkait dengan kisah pengguna . Jika pengguna cerita menggunakan istilah "login", maka pernyataan tidak dapat mengubah istilah ini untuk mengotentikasi / mengesahkan / memvalidasi. Jika cerita tidak ditulis dengan baik, ubahlah.
Kedua,
spesifikasi harus secara eksplisit memuat nama komponen yang mereka gambarkan. Ini menunjukkan area pengujian dan menandakan kesalahan, jika tiba-tiba osprey sering menyertakan beberapa komponen yang tidak terduga.
Skrip yang valid dikombinasikan dengan prinsip tanggung jawab Tunggal, sehingga nama komponen harus cocok dengan deskripsi tes. Jika ada banyak skenario yang valid, maka mungkin komponen tersebut memiliki tanggung jawab terlalu banyak.
Juga, satu skenario, sebagai suatu peraturan, menggambarkan suatu peristiwa ui atau semacam pola. Kandidat yang baik untuk nama komponen dapat berisi nama pola: Validator, Strategi, Builder, Transformer, Controller, dll. Atau nama acara: Submitter, Login, ReadonlyOrderView, dll. Yaitu tergantung pada nama komponen, baik nilai input dan output dari fungsi utama kelas harus ditentukan. Nama buruk: terlalu abstrak (Layanan, Komponen, Pembantu, Utilitas) dan ganda (ValidatorAndRenderer).
Ketiga,
spesifikasi harus secara eksplisit menyatakan kondisi .
Buruk:
@Test public void testValidatePassword(){}
Lebih baik:
@Test public void loginController_whenValidUsername_andValidPassword_shouldLogUserIn(){}
Kami tidak harus memanggil fungsi ini dari tempat lain, jadi nama ekstra panjang itu valid. Jika jumlah kondisi dalam tes tidak sesuai pada garis, maka mungkin Anda harus mengubah struktur komponen.
Untuk tes javascript hal yang sama, tetapi Anda dapat menempatkan kondisi di sana, ternyata lebih nyaman.
describe('login UI component', () => { describe('when username provided', () => { describe('when valid password', () => { it('should log user in', () => { ... }); }); }); });
Kondisi eksplisit lebih mudah dibaca dan
hilang .
Selain itu, jika kondisinya tidak cocok dengan kode tes tertulis, maka kodenya mudah diperbaiki.
Penjelasan yang baik adalah, secara umum, pengganti untuk dokumentasi dan komentar kode. Ini abstrak, tidak tergantung pada framework dan compiler, dan harus diperlakukan dengan keseriusan yang sama seperti dua yang terakhir.
Kondisi itu sendiri harus konsisten dalam kode agar mudah dibaca, misalnya DIBERIKAN-KETIKA-HARUS-HARUS, dll.
Keempat,
spesifikasi harus disederhanakan . Berguna untuk menuliskannya dalam urutan terbalik:
Kesalahan pertama, nulls pertama, happy path last. Maka tidak ada keinginan untuk menyelesaikan pengujian setelah satu kasus pengguna yang valid. Untuk komponen UI: rendering, acara. Untuk komponen stateful, semua state konsisten.
Dengan demikian, struktur spesifikasi yang dapat dibaca terlihat seperti ini: 5-10 salah, satu skrip yang valid (atau beberapa variasi satu skrip)
Ini adalah praktik yang baik ketika menulis spesifikasi untuk menuliskannya secara penuh dalam bentuk teks, dan kemudian memberikannya kepada seorang kolega untuk membaca untuk kejelasan dan kondisi yang hilang. Kemudian, sebenarnya, Anda sudah dapat mulai menulis implementasinya. Cukup sering, dalam bentuk ini, tugas diasingkan, yaitu baik, ketika orang lain menulis implementasi ujian.
Kelima,
implementasi tes harus sesuai dengan apa yang tertulis dalam uraian .
Ini adalah praktik yang baik untuk membagi menjadi mengatur-bertindak-menegaskan untuk dengan mudah menemukan kecocokan untuk satu atau bagian lain dari implementasi. Teks asersi dan pengecualian, jika ada, juga harus dikorelasikan dengan deskripsi tes, sebagai aturan, kita bisa menduplikatnya.
Tak perlu dikatakan, ketika menambahkan kondisi atau pernyataan untuk tes, Anda juga perlu memperbarui deskripsi tes.
Jadi, urutan penulisan spesifikasinya bisa sebagai berikut.
- baca cerita pengguna
- komponen nama dan skrip yang valid
- merumuskan kondisi untuk skenario yang valid
- melengkapi spesifikasi dengan skrip yang salah dengan menempatkannya di atas
- biarkan tetangga membaca dan memperbaiki yang hilang
- mengimplementasikan tes dan komponen satu per satu menggunakan loop merah-hijau-refactor.