Artikel ini didasarkan pada postingan di saluran telegram Cross Join .
Sebelum berbicara tentang pendekatan ini, pertama-tama saya akan menjelaskan secara singkat apa itu pengujian mutasi secara umum. Bagi mereka yang belum tahu.
Pengujian mutasi
Saat Anda menulis tes, TDD atau tidak, bahkan dengan cakupan formal 100%, Anda tidak akan pernah yakin bahwa semuanya benar-benar diuji dalam kode. Misalnya, mungkin saja membuat kesalahan kecil dalam memanggil assert dalam pengujian itu sendiri.
assertEquals($a, $a);
Dan jika bahkan selama pengujian itu mungkin untuk mencapai beberapa jika, itu bukan fakta bahwa semua kondisi jika diperiksa dengan benar.
Untuk memastikan bahwa pengujian tersebut benar-benar menguji, ada cara seperti itu: memasukkan sendiri bug ke dalam kode, dan melihat apakah pengujiannya tidak sesuai dengan kondisi ini. Jika tes masih hijau dengan bug yang jelas, maka tidak semuanya telah diuji.
Misalnya, Anda mengubah plus menjadi minus, atau menambahkan "tidak" ke kondisi, dan melihat apakah tes bereaksi. Pendekatan ini disebut "Pengujian Mutasi".
Ini biasanya dilakukan di area pemrograman yang sangat kritis, di mana kesalahan biasanya tidak diperbolehkan. Misalnya, perangkat lunak penjelajah atau perangkat lunak medis.
Tentu saja, dalam konstruksi penjelajah, ini semua dilakukan secara otomatis: sebuah alat khusus menodai program Anda dan melihat apakah pengujian telah gagal.
, , , , , . : AST, .
Mutation Driven Development
mutation driven development. TDD, .
- , ( )
- ( if). , , MDD (?) , 100% overage TDD.
, CI, , , MDD .
, , . mutation driven testing , . , .. , , , , , ., 95% , - -. , .
Kami tentu saja akan membahas pengembangan yang didorong mutasi di salah satu Penjualan Seng yang akan datang , jangan lupa untuk berlangganan podcast