Der Artikel basiert auf einem Beitrag im Cross Join- Telegrammkanal .
Bevor ich über diesen Ansatz spreche, werde ich zunächst kurz erläutern, was Mutationstests im Allgemeinen sind. Für diejenigen, die nicht Bescheid wissen.
Mutationstests
Wenn Sie Tests schreiben, TDD oder nicht, werden Sie selbst bei einer formalen 100% igen Abdeckung nie sicher sein, dass tatsächlich alles im Code getestet wird. Zum Beispiel ist es möglich, einen blöden Fehler beim Aufrufen von assert im Test selbst zu machen.
assertEquals($a, $a);
Und wenn es sogar während des Testens möglich war, einige if zu erreichen, ist es nicht eine Tatsache, dass alle Bedingungen in diesem if korrekt überprüft werden.
Um sicherzustellen, dass die Tests wirklich getestet werden, gibt es eine Möglichkeit: Fehler selbst in den Code einzufügen und zu prüfen, ob die Tests nicht dazu passen. Wenn die Tests immer noch grün sind und einen offensichtlichen Fehler aufweisen, wurde nicht alles getestet.
Sie haben beispielsweise das Plus in ein Minus geändert oder der Bedingung "nicht" hinzugefügt, um festzustellen, ob die Tests reagiert haben. Dieser Ansatz wird als "Mutationstest" bezeichnet.
Dies geschieht normalerweise in sehr kritischen Bereichen der Programmierung, in denen Fehler im Allgemeinen nicht zulässig sind. Zum Beispiel Rover-Software oder medizinische Software.
Bei der Rover-Konstruktion erfolgt dies natürlich automatisch: Ein spezielles Tool entstellt Ihr Programm und prüft, ob die Tests fehlgeschlagen sind.
, , , , , . : AST, .
Mutation Driven Development
mutation driven development. TDD, .
- , ( )
- ( if). , , MDD (?) , 100% overage TDD.
, CI, , , MDD .
, , . mutation driven testing , . , .. , , , , , ., 95% , - -. , .
Wir werden natürlich die mutationsgetriebene Entwicklung in einem der kommenden Zinkverkäufe diskutieren. Vergessen Sie nicht, den Podcast zu abonnieren