Di antara banyak TDE pseudo-ida yang mengorbit, ada beberapa yang mengabaikan uji ganda, tidak sedikit terkait dengan nama-nama konyol mereka.
Mereka akan memanggil mereka entah bagaimana dengan bangga, kalau tidak mok, rintisan, palsu - perasaan bahwa kita tidak benar-benar kehilangan apa pun jika kita tidak menggunakannya. (Berbeda dengan "tes integrasi" dan "dependensi nyata").
Namun, Anda dapat mengubah sudut pandang. Pada akhirnya, mock tidak hanya mendukung komponen dependen, tetapi juga menentukan perilaku dependensi. Dan implementasi "nyata" adalah perwujudan ide kebanggaan kami saat ini, yang mungkin salah.
Dalam pengertian ini, setiap kali kita menulis
when(mockDependency.method(inputValue)).thenReturn(returnValue) ,
kami mendokumentasikan beberapa perilaku komponen.
Karenanya ada beberapa konsekuensi.
Benda-benda tiruan terhubung erat dengan spesifikasi tes yang sebenarnya, baik dalam kosakata maupun dalam arti. Baik itu dan yang lain memfokuskan kita pada persyaratan dan skenario, tetapi tidak pada fitur implementasi saat ini.
Fakta bahwa pernyataan tentang komponen yang harus dibasahi ketika menggunakan kerangka kerja seperti Mockito agak mengganggu bagi kita tersebar di antara kelas klien, dan sulit untuk melacaknya. Dalam pengertian ini, kelas turunan eksplisit dengan perilaku yang telah ditentukan lebih disukai daripada mengejek seperti Mockito, karena mereka memungkinkan Anda untuk merangkum skrip dan melihatnya secara sekilas.
Dengan demikian, kelas skrip ValidOrderProviderStub, ExpiredOrderProviderStub, InvalidOrderIdException_OrderProviderStub, OnlyOnceOrderProvider dan sebagainya, yang bisa dalam paket yang sama dan digunakan oleh semua tes sekaligus, ditambahkan ke setiap kelas OrderProvider.
Ini termasuk kelas mata-mata yang mudah diterapkan sendiri.
Selain itu, pendekatan ini lebih cepat untuk dieksekusi dan bekerja tanpa menggunakan refleksi.
Jadi, ketika membaca kode, kita dapat membuat konvensi bahwa keberadaan mok mengkonfirmasi kemungkinan sebuah skrip, dan ketidakhadirannya melarang keberadaan skrip semacam itu. Jika kita melarang kelas klien untuk menulis harapan mockito, maka dalam pencarian NullOrderProvider ternyata tidak ada mock yang cocok, karena null tidak pernah kembali, dan oleh karena itu tidak masuk akal untuk menguji skenario ini.
Jika mok adalah spesifikasi, maka mok adalah cerminan dari rencana kami untuk suatu komponen, dan mereka dapat dan harus ditulis sebelum implementasi.
Jika mok adalah spesifikasi, maka itu hirarkis dan mencerminkan perilaku komponen tergantung pada kondisi tertentu.
Dengan demikian, moki kami dapat menggandakan terlalu banyak: moki tanpa syarat selalu mengembalikan yang sama, serta moki dengan kondisi internal, seperti untukIdOne_returningOne_forIdTwo_ReturningTwo_OrderProvider. Penghitungan terakhir dan Anda hanya perlu membuat FakeOrderProvider dengan perilaku yang sesuai, yang harus disinkronkan dengan implementasi yang sebenarnya.
Dengan demikian, jika mok adalah spesifikasi dari perilaku tertentu, maka implementasi komponen tidak lebih dari menyinkronkan perilaku komponen dengan moknya.
Dan ini, mungkin, adalah argumen utama terhadap massa - kebutuhan untuk menyinkronkan perilaku mereka dengan implementasi nyata saat ini, kita akan membicarakan hal ini secara terpisah di lain waktu.