Наскоро (на последното ни виждане за по бира) се спомена за този тип тестване. Накратко казано се прави следното:

* един човек пише основния код
* някой друг пише юнит тестове за основния код
* трети човек прави тест за това колко добре са написаните юнит тестовете като настройва един "mutation engine" - този енджин прави случайни промени по основния код (променя някои константи, променя >= с > или обратното и т.н.) и проверява дали юнит тестовете ще хванат всички мутации

Всичко това има смисъл да се прави когато проекта има изключително високи изисквания за качество/надежност (може би ако зависят човешки животи от него и т.н.). Най-вероятно такива високи изисквания има в автомобилната, авио- и космическата индустрия.

На някой случвало ли му се е да работи по такъв проект (с такива изисквания)?

За safety приложения си има стандарт/и и там си има изисквания, има и общоприети модели за развой. Относно тестовете се изисква 100% coverage на кода от тест кеисовете, но това е необходимо, но не достатъчно условие. Изисква се и статичен анализ на кода. И отказ от определени екстри като динамична памет например ... И следене да не се прехвърли определено ниво на сложност на кода (измерено от статичните анализи). Сега като гледам какъв лимит бяха избрали нашите хора е малко спорно - в смисъл книгите говорят да не се превишава едни други нива и странно ние как сме избрали че е ок да допускаме 3-4 пъти по-висока сложност, но TUV и те са хора явно ...
Сега, как се гарантира че тест кеисовете са достатъчно - при нас се гонеше основно 100%-те процента coverage. А допълнително се следваше процес на работа, които да изведе необходимите кеисове - доколкото си спомням това беше малко на доверие, в смисъл че се разчиташе на разработващия и проверяващия да са избълвали достатъчно. Имаше си типичен чек лист какви неща да се гонят в кода - препълвания, инфлексни точки, граници, разни специфики по flow-а на кода.
Това с мутациите не съм го чувал, интересен подход но аз винаги питам какво гарантира - в смисъл дадения инструмент/подход гарантира ли че ще хване всичко? Ако не, т.е. ако просто добавя още малко спокойствие че е минал "и той" не е голяма далаверата. Нещо като fuzz тестовете - ако имаш достатъчно мощност в клъстъра може да се надяваш и той да хване нещо отгоре, но докато не извърти всички комбинации и то във всички последователности няма гаранция.
Аз съм привърженик на друг подход - разработването на кода да става така че тестването да е максималко улеснено. Това е дълбока тема, но общо взето значи да се ползват само pure функции. Това решава няколко проблема - изключва наличието на скрити зависимости в кода, изважда алгоритмите и ги отделя от данните, и прави ненужно писането на mock-ове.
То мисля е ясно, но да се търси начин как да се изтества "някакъв" код, след като е разработен и написан, е загубена кауза. Идеята на TDD е основно да се улеснява процеса на тестване (и повтаряемост), което като ефект носи качество на кода.

gicho, недей търси какво гарантира. Пускането на тестовете върху целенасочено мутиран код могат да ти дадат някаква оценка за качеството на тестовете.
Става въпрос за още един инструмент, а не за метод трепач, който ще избие рибата.

Баси мамата - тестове за проверка на кода и после мутации за проверка на проверяващите тестове, после сигурно следва тестове за проверка на тестовете на проверяващите тестове . Миналия месец при нас измислиха едни хора да проверяват работата на едни други хора и после тия другите хора д проверяват проверката на проверяващите хора. Като резултат вече ми отнема 2-3 седмици машинните инженери да ми направят чертеж за нещо, за което преди отиваха най-много два дена. Веселото в цялата история е, че нито качеството се подобри, нито грешките изчезнаха - просто щата се разду и се хабят ресурси като за световно .

отговора е прост Цивилизованият свят се пълни с дипломирани бюрократчета прекарващи цял живот пред бюрце. Те работа и реален продукт не създават, обаче за да съществува цивилизованият свят трябва нещо (нищо) да работят пък заплати да изкарват... В софия в последните години се нароиха софт фирми, много от тях се занимават само с тест на софтуер. В южните квартали на софия и южен парк вече повече чужда отколкото българска реч се чува......

Леле, мале... като гледам на къде се насочва темата... поне някой от вас направи ли си труда преди да пише да прочете за какво иде реч. За това, да помисли над прочетеното няма да питам.
Unit и module test на кода на никого не гарантират 100% нищо. Чисто и просто помагат дребни проблеми да се хванат много по-рано, преди да са стигнали по-надалеч по веригата например при клиента или крайния потребител. Което също означава извън компанията, която разработва продукта - съответно повече разходи, време и прочие(ресурси) за неща които могат да се хванат овреме.
В 95% от случаите тези тестове са автоматизирани до някаква степен и никакво раздуване на щата с бюроподпирачи не се подразбира.
Тестовете и те се пишат от хора и идеята за проверка на тестовете, е просто още едно помощно средство, инструмент.
Когато се изисква качество и надеждност тестовете не свършват с юнит и модул тестове на софтуера.
Ама виждам че тука има хора, които знаят по-добре и такива на които им е през оная работа.

Софтуер! Това е бъдещето! Бизнесът с тест ще расте! Купувайте акции на компании занимаващи се с това и пишещи софтуер за автоматизация! Цените винаги ще растат!

В миналото преди 2010 се занимавах с мед. техника. Пишеше се основно на асемблер (особено преди 2005). Не се използваха никакви библиотеки. Добре подреден код. Разписани алгоритми на 100ци страници и проверки от доста хора. Изделията имаха цветни дисплей, бутони, движещи части и т.н. Но електрониката, която софтуера управлява е направен железен от хора които наистина разбират. Така че софтуера да се скапе на 100% електрониката нищо страшно няма да направи.
В днешно време нещата не стоят така - електрониката става все по-калпава (с цел ниска цена), софтуера става на все по-високо ниво, тъй като user интерфейсите и комуникациите все по сложни и набутани във всичко. А хората които пишат софтуера са все по-далеч от електрониката.

Ти остави софтуера... Зелето кажи стана ли.

Мхм, статистически методи за подобряване, аналогични на хвърляне на повече единици в боя. Както Zdrav е загатнал, това не е панацея.

Иначе за 100% единствения метод за който знам е формално доказателство, което си е чиста проба математика. Има доста копане в тази област, вкл. и езици, ама не решават всякакви проблеми а и сложността гръмва бързо.

Та да не се забравя старата максима - "Program complexity grows until it exceeds the capability of the programmer who must maintain it".

давате храна на офис планктона

Формалното доказване (обосноваване) е нещото което година-две ме влече към функционалните езици. Но за ембедед не е много разпространено, и ако навлезе ще е по-скоро от това че "ембеддед" почва да се води 4 ядра с 1-2гиги рам.
По-точно functional reactive програмирането е много добра концепция.
А при TDD има още една цел, освен проверката на текущия код - и тя е натрупване на база от тестове които лесно да хващат счупвания в кода и регресии. Което променя начина на писане и ефективността - ако знаеш че на post build стъпка имаш сериозен набор от кеисове, които ако се спазва модела за lock-step между тест кеис и имплементация в кода гарантират сериозно покритие, много лесно се оптимизира и рефакторира.
А lock step изисква като ти хрумне дребна функционалност която трябва да прави софтуера, например проверка за нулев поинтър аргумент, да напишеш първо тест кеис който да гръмне понеже е нямало досега проверка, после да добавиш проверката и тест кеиса да не гърми повече (заедно с всички останали на този модул).
Интересното е какво става ако направиш тест кеиса за нулев поинтър, и софтуера не иска да гръмне? Излиза че нямаш нужда от такъв кеис, или от самата проверка - явно в кода няма проблем който да можеш да "оправиш"...

Тя сложността отдавна е гръмнала. И в софтуера и в хардуера.

Това вече (в днешно време) е частен случай. Иначе е добра максима.

Тези 100% покритие знаете са относителни и ако става въпрос за "one man show" са и много субективни.
Ето ако, както казваш gicho, ти хрумва някаква функционалност и от там пишеш код и тест, кой друг ще разбере какво ти е хрумнало и защо. Дори и ти самия след време ще ти хрумне нещо друго, ще промениш кода и тогава вече теста за NULL pointer може и да почне да гърми(ако все пак си го написал).
За по-сложни системи и проекти това не върви. Трябва ти обективен и разбираем за всички работещи по него, сорс. Дали ще е на асемблер или С или функционален език, не е толкова важно. Важното е кода, тестовете, документацията и пр. да идват от един източник - сорс. Тогава и 100-те процента покритие ще бъдат по-близо до обекхивната оценка.
И най-добре ако се генерират от този сорс с минимум човешка намеса.
Но разбира се не живеем в идеален свят. В океана има много планктон, китовете намаляват...
А сложността отдавна е гръмнала.

Не се хващай за думата, това "хрумва" беше за цвят - имам предвид когато се наложи да се прави определена функционалност, change request. Погледнато в обратната посока зад всяка функционалност в кода трябва да има обосновка защо я правим (защо сме изхарчили пари по писането и). Така че тя идва от някаква нужда дошла отгоре - декопозирана от по-голяма заявка от маркетинга примерно, или бъг репорт - изобщо някаква issue заради което ние сме затворили мцу-бг и сме пуснали иде-то...
Аз лично (все още) не го спазвам напълно това правило за lock-step-а, признавам - но така пише по книгите и логиката е абсолютно вярна.
При лок степа идеята да няма ред/израз от кода който да е оставен без тест кейс. Другото важно в тази концепция е че тези unit тестове се правят от един човек - от програмиста. Т.е. не се правят от двама - програмист и тестер. Това е важно тъй като само програмиста може да има познанието на това ниво и да подготви реален тест кейс, и опит да се разпредели това между двама ше е неефективно. За тестерите (които могат да са програмисти в ролята на тестер в момента) остават модулни, интеграционни и т.н. тестове.
В смисъл, ако не е така, някой трябва да дефинира други правила как и кога пишем тест кеис. И обикновено става "ами всичко което ти хрумне" и според това колко си пил снощи правилото вади различни резултати - от 0 до 2-3.

Ето една книжка по въпроса:


А относно генерирането съм съгласен - само че сорса не е възникнал вследствие на вчерашното преяждане. За да се получи той е имало описание на изисквания, модел или нещо в този ред. Тези "входни данни" водят до сорса. Най-добре е ако това описание е "формално" - и може да бъде проверено (обосновано, моделирано, доказано) преди да има и един ред код. И после кода да се проверява дали отговаря на формалните изисквания.
Т.е. кода е пак "трансформация" на информацията която е дошла с изискванията (заданието). Ако кода не прави всички точно както пише в заданието е проблем, ако кода прави нещо което не го пише в заданието е проблем (може би на заданието). По същия начин документацията е трансформация на заданието, тестовете са трансформация на заданието.
Качественото задание (модел в математически, UML, DSL или подобен вид) е входната точка - изисквание, лимитации, ограничения. Оттам насетне ние сме свикнали да има "ръчна" работа по кодиране на сорс, тестове и т.н. Ако има наличния инструментариум и достатъчно пълно описание може да се направи автоматично генериране. Но това изисква определена критична маса - както казват, всяко допълнително ниво на абстрактност изисква определен обем от работа за да се обоснове (изплати) инвестицията в разработването на инструментариум за работа с него.
При функционалните езици има директна аналогия с математически модели и това води до бонуса от "лесно" обосноваване на кода. При обектни/процедурни и подобни такава връзка няма и трябва да се слага "glue logic" под формата на стандарти, езици, фреймуърки, тестове, валидации, документации, правила, стилове, ...

Щом заговорихме за задание/спецификация, изисквания това вече е друго нещо. Различно от гарантираните 100%.
Не винаги тестера е само тестер, знаеш. Има вариант когато един пише кода на един компонент, друг тества, но за друг компонент си разменят шапките. Първия пише теста на кода който е написал втория или някой друг. Практиката тестове да се пишат само от новобранците намирисва на отбиване на номера.
Темата не беше точно за тестове по принцип. Не е и за TDD.
Но поне не мерим кой е полутвърд и кой полумек.

Това което исках да разбера е: (1) дали някой е работил по такъв проект и ако да - (2) дали този вид тестване наистина води до хващане на проблеми в кода, който върши работата?

Ясно е, че този вид тестване ЩЕ ХВАНЕ проблеми в юнит тестовете, но в крайна сметка не те са на полето, а истинския код!