Re: Тестване чрез мутации на кода
Не разбрах? Ако има проблем в юнит теста значи съответното проверявано от него нещо (feature) в кода не се знае дали работи (щото все едно не е тествано като не е правилен теста). Все едно да кажеш че понеже юнит теста не иска да се билдва или не минава това не е проблем, щото ти сорса ще доставяш, а не теста...
Ако въпросът е дали юнит тестовете помагат изобщо, при положение че "те не са на полето", мисля че е излишно да се отговаря.
А ако питаш по-реалното дали има нужда, и как се проверява качеството на юнит тестовете, то нямам друг отговор освен онова горе - разработване на тест кеис за всеки ред/израз (feature) от написания код. От моя опит не съм намерил никакъв друг подход, които да постига нещо в тая насока.
Има един подход наречен design by contract - пълна аналогия на това как би уредил бизнес отношенията със съмнителен бизнес партньор - изпълнител или възложител. А именно с добре разписан договор, който горе наричаме задание / изисквания. Прилага се за да се дефинира интерфейс между компоненти в софтуера, така че те да останат независими и все пак накрая да работят заедно.
Там логиката е изчистване на конктракта до последния детайл, ако ще и това да бъде въпрос на итерации (анекси
). Който не се поти на пазарлъка се поти на работата после... И така.
Другото което опитах са загатна е че без дефиниран контракт (договор), т.е. без прецизирани изисквания, няма как да се стигне до смислено покритие от тестове - просто тогава (ако не са изчистени) се залага на усета и опита на участващите хора, но и на нещо друго субективно - на "настроението" на човека - препил, влюбен, мързелив.
Удоволствието идва когато имаш изчистено задание (което може да ти е струвало повече време отколкото програмирането) и по него просто кодираш. Тогава имаш спокойствието че няма какво да се счупи, но и няма нищо излишно в кода (т.е. не си се потил излишно за работи, които никой не използва).
Това да се постигне напълно е химера - но тук говорим за подходи или добри практики, всеки е свободен да ги ползва или не.
Лошото е че рядко може да се намери клиент, който да се навие на този подход - трябва да е човек които си разбира от работата и да е наясно с инжинерния труд. Иначе разните мениджъри нямат този поглед и за тях ползите не са примамливи - само пост фактум можеш да им обясниш как грешно решение в някакъв момент в миналото е довело до преразход по-късно - ама то след дъжд качулка.