Статья написана на основе поста в telegram-канале Cross Join.
Прежде чем рассказать об этом подходе сначала в двух словах объясню, что такое мутационное тестирование вообще. Для тех, кто не в курсе.
Мутационное тестирование
Когда вы пишете тесты, по TDD или нет, даже с формальным 100% покрытием, вы никогда не будете уверены в том, что в коде на самом деле протестировано всё. Например, можно банально ошибиться в вызове assert в самом тесте.
assertEquals($a, $a);И если даже при тестировании удалось дойти до какого-то if, не факт, что в этом if правильно проверены все условия.
Чтобы убедиться в том, что тесты реально тестируют, есть такой способ: самому вносить в код баги, и смотреть, валятся ли от этого тесты. Если тесты по-прежнему зелёные при явном баге, значит протестировано не всё.
Например, заменили плюс на минус, или добавили "не" к условию, и смотрите, отреагировали ли тесты. Такой подход называется "Мутационное тестирование".
Обычно это делают в очень ответственных областях программирования, где ошибки вообще не допустимы. Например, софт марсохода или медицинское ПО.
Конечно в марсоходостроении это все делается автоматически: специальный инструмент уродует вашу программу и смотрит, слетели ли тесты.
Проблема в этом подходе в том, что это довольно муторно настраивается, много нюансов, как описать, что надо мутировать, что нет. И всё это потребляет дикое количество ресурсов: разбор кода в AST, мутирование и обратное преобразование.
Mutation Driven Development
Сейчас некоторые авторы предлагают подход mutation driven development. Он аналогичен TDD, но как бы наоборот.
- сначала добавляете новый код в проект
- временно вносите баг
- пишете тест, который ловит этот баг (или фиксите старые тесты)
- переходите к следующей строке (или к следующей части условия if). Конечно, и здесь можно случайно пропустить кусок логики, но в целом MDD (?) гораздо более упорот, чем 100% сoverage или TDD.
Для меня такой подход видится интересным тем, что можно ничего не настраивать в CI, не просить выделить доп ресурсы для обработки пайплайнов, а просто писать более покрытый код, даже если тимлиду или вообще никому в твоей команде в целом MDD неинтересен.
Конечно, это не бесплатно, и нещадно пожирает ресурсы программиста. Имхо mutation driven testing можно и нужно применять только там, где есть ответственная логика. Работа с деньгами, медицинский софт и т.д. Понятно, что на эндпоинт, выдающий текущую погоду или прочую ерунду, можно не тратить ресурсы, как ручные, так и автоматические.Вообще, множество проектов содержат 95% стандартного бойлерплейта, и лишь чуть-чуть важной бизнес-логики. Вот эту важную логику при желании можно довести до состояния, близкого к идеалу.
Конечно же мы обсудим mutation driven development в одном из ближайших выпусков "Цинкового прода", не забудьте подписаться на подкаст
ilitaixperta
Вместо обсуждения этой неинтересной статьи хочу поговорить с вами о таком процессе, который я называю моргенштернизация IT.
Не подумайте, я не собираюсь хейтить Моргенштерна, он умный чувак. Он просто понял как работает хайп и что надо делать чтобы хайпануть. Поэтому он вообще не пытается делать классную и интересную музыку, он четко понимает какое говно зайдет людям и делает именно это говно. Только для того чтобы получить хайп.
Айти же давно превратилось в массовку, где большинство в профессии шарит на уровне ценителей Моргенштерна. И поэтому тут тоже можно хайповать. Только для этого нужен рецепт хайпа.
И этот рецепт хайпа в ойти прост — берешь всем известную или никому не нужную вещь из модной темы (Ну что там сейчас модно? Ммм тестирование, аджайл, тайм-менеджмент и т.п.), немного видоизменяешь чтобы казалось что сам придумал, клеишь модный ярлычок и форсишь везде где можешь. Макаки ведутся, хайп вместе с самооценкой растет, можно еще и подкаст заодно порекламить.
Только автор толком ниасилил, взял TDD (который тоже какойто недоморгенштерн по этой же схеме 100 лет назад придумал), переименовал в Mudation Driven Development и пытается расфорсить.
Каким же жалким надо быть, чтобы вместо того чтобы создавать крутые продукты, проектировать новые технологии, изобретать новые вещи, сидеть и пытаться раздуть никому не нужную мелочную херную до хайповой темы? Только для того чтобы потешить свое чсв перед макаким, которых нормальные специалисты презирают.
varanio Автор
Я согласен, что термины придумывают направо и налево. Например, гексагональная архитектура — бред в общем-то.
Однако в mutation driven development я все же вижу рациональное зерно.
Что касается вашего комента, то он содержит и новый пафосный термин Моргенштеризация, и чсв 80 уровня — короче всё то, против чего вы боретесь.
Ну и еще и оскорбления.
ilitaixperta
Есть вагон людей, которые и в TDD видят рациональное зерно. Хотя это такой же высосаный из пальца бред ради хайпа. Я «борюсь» против того, чтобы расхайпованная бредятина не превращалась в индустрии в best practice
varanio Автор
Если бы ваши комменты были менее токсичными, ваш рейтинг (карма) была бы повыше.
Вместо аргументов идет злоба, оскорбления. Это просто раздражает, не более того: никакой осмысленной позиции не вижу что-то.
ilitaixperta
Аргументация в моих коментах есть, просто вы ее игноируете
Вы написали высосаную из пальца статью, про высосаную из пальца никому не нужную методологию, чтобы попиарить свой никому ненужный блог с 3.5 подписчиками и подкаст, который ведете чтобы набить плюсиков в популярность, чтобы подороже продаться.
Достаточно аргументировано? Или назовете эти факты оскорблениями?
А теперь вы пытаетесь сделать хорошую мину при плохой игре, но сказать вам особо нечего, что хорошо видно по вашему безжизненному комментарию
varanio Автор
Под аргументами я понимаю что-то связанное с сутью статьи: разработка через мутации. А не переходы на личности и выяснения, кто чей блог шатал.
Такая неинтересная статья, такой неинтересный комент, ну так читайте интересные статьи и коменты.
«Я три дня гналась за вами, чтобы сказать, как вы мне безразличны»
ilitaixperta
Если вы вдруг забыли на какой комент отвечали, то напомню: эта ветка коментов не про вашу статью, а про моргенштернизацию (лел) ойти, частью которой вы являетесь. И именно об этом процессе я всю ветку говорю, а не о вашей статье — она нахрен никому не сдалась.
Хотите чтобы люди обсуждали ваши статью по сути, добавьте туда суть. Пока что там обсуждать нечего.
Если хотите чтобы вас не обсирали, не давайте повода для этого. А не указывайте людям что им делать.
varanio Автор
> Если хотите чтобы вас не обсирали, не давайте повода для этого.
Да мне в общем всё равно, это всего лишь коменты на хабре. Пишите что хотите. Просто удивляюсь такому живому интересу к неинтересному.
В целом теперь мне уже стало неинтересно обсуждать тут. Бессмысленный срач.
amarao
TDD — это очень тонкая методология, и она касается даже не процесса написания основного кода, а процесса создания новых фич. Причём, лучше всего оно работает для машиноориентированных фич. Пишешь тест под несуществующую фичу и в этот момент (будучи потребителем API) хорошо и плотно думаешь о том, как эту фичу сделать удобной (себе). Думаешь до того, как пишешь, что бесценно.