Mutation Driven Development

    Статья написана на основе поста в telegram-канале Cross Join.


    Прежде чем рассказать об этом подходе сначала в двух словах объясню, что такое мутационное тестирование вообще. Для тех, кто не в курсе.


    Мутационное тестирование


    Когда вы пишете тесты, по TDD или нет, даже с формальным 100% покрытием, вы никогда не будете уверены в том, что в коде на самом деле протестировано всё. Например, можно банально ошибиться в вызове assert в самом тесте.


    assertEquals($a, $a);

    И если даже при тестировании удалось дойти до какого-то if, не факт, что в этом if правильно проверены все условия.


    Чтобы убедиться в том, что тесты реально тестируют, есть такой способ: самому вносить в код баги, и смотреть, валятся ли от этого тесты. Если тесты по-прежнему зелёные при явном баге, значит протестировано не всё.


    Например, заменили плюс на минус, или добавили "не" к условию, и смотрите, отреагировали ли тесты. Такой подход называется "Мутационное тестирование".


    Обычно это делают в очень ответственных областях программирования, где ошибки вообще не допустимы. Например, софт марсохода или медицинское ПО. 


    Конечно в марсоходостроении это все делается автоматически: специальный инструмент уродует вашу программу и смотрит, слетели ли тесты. 


    Проблема в этом подходе в том, что это довольно муторно настраивается, много нюансов, как описать, что надо мутировать, что нет. И всё это  потребляет дикое количество ресурсов: разбор кода в AST, мутирование и обратное преобразование. 


    Mutation Driven Development


    Сейчас некоторые авторы предлагают подход mutation driven development. Он аналогичен TDD, но как бы наоборот. 


    1. сначала добавляете новый код в проект
    2. временно вносите баг
    3. пишете тест, который ловит этот баг (или фиксите старые тесты)
    4. переходите к следующей строке (или к следующей части условия if). Конечно, и здесь можно случайно пропустить кусок логики, но в целом MDD (?) гораздо более упорот, чем 100% сoverage или TDD.

    Для меня такой подход видится интересным тем, что можно ничего не настраивать в CI, не просить выделить доп ресурсы для обработки пайплайнов, а просто писать более покрытый код, даже если тимлиду или вообще никому в твоей команде в целом MDD неинтересен. 


    Конечно, это не бесплатно, и нещадно пожирает ресурсы программиста. Имхо mutation driven testing можно и нужно применять только там, где есть ответственная логика. Работа с деньгами, медицинский софт и т.д. Понятно, что на эндпоинт, выдающий текущую погоду или прочую ерунду, можно не тратить ресурсы, как ручные, так и автоматические.Вообще, множество проектов содержат 95% стандартного бойлерплейта, и лишь чуть-чуть важной бизнес-логики. Вот эту важную логику при желании можно довести до состояния, близкого к идеалу.


    Конечно же мы обсудим mutation driven development в одном из ближайших выпусков "Цинкового прода", не забудьте подписаться на подкаст

    Комментарии 14

      –8
      Вместо обсуждения этой неинтересной статьи хочу поговорить с вами о таком процессе, который я называю моргенштернизация IT.

      Не подумайте, я не собираюсь хейтить Моргенштерна, он умный чувак. Он просто понял как работает хайп и что надо делать чтобы хайпануть. Поэтому он вообще не пытается делать классную и интересную музыку, он четко понимает какое говно зайдет людям и делает именно это говно. Только для того чтобы получить хайп.

      Айти же давно превратилось в массовку, где большинство в профессии шарит на уровне ценителей Моргенштерна. И поэтому тут тоже можно хайповать. Только для этого нужен рецепт хайпа.

      И этот рецепт хайпа в ойти прост — берешь всем известную или никому не нужную вещь из модной темы (Ну что там сейчас модно? Ммм тестирование, аджайл, тайм-менеджмент и т.п.), немного видоизменяешь чтобы казалось что сам придумал, клеишь модный ярлычок и форсишь везде где можешь. Макаки ведутся, хайп вместе с самооценкой растет, можно еще и подкаст заодно порекламить.

      Только автор толком ниасилил, взял TDD (который тоже какойто недоморгенштерн по этой же схеме 100 лет назад придумал), переименовал в Mudation Driven Development и пытается расфорсить.

      Каким же жалким надо быть, чтобы вместо того чтобы создавать крутые продукты, проектировать новые технологии, изобретать новые вещи, сидеть и пытаться раздуть никому не нужную мелочную херную до хайповой темы? Только для того чтобы потешить свое чсв перед макаким, которых нормальные специалисты презирают.
        +1
        Я согласен, что термины придумывают направо и налево. Например, гексагональная архитектура — бред в общем-то.

        Однако в mutation driven development я все же вижу рациональное зерно.

        Что касается вашего комента, то он содержит и новый пафосный термин Моргенштеризация, и чсв 80 уровня — короче всё то, против чего вы боретесь.

        Ну и еще и оскорбления.
          –1
          Что касается вашего комента, то он содержит и новый пафосный термин Моргенштеризация, и чсв 80 уровня — короче всё то, против чего вы боретесь.
          Ну это вы просто пытаетесь высосать из пальца ответ мне. Если бы ваша статья не была пустой и неинтересной, коментов и рейтинга у нее было бы побольше

          Однако в mutation driven development я все же вижу рациональное зерно.
          Есть вагон людей, которые и в TDD видят рациональное зерно. Хотя это такой же высосаный из пальца бред ради хайпа. Я «борюсь» против того, чтобы расхайпованная бредятина не превращалась в индустрии в best practice
            –1

            Если бы ваши комменты были менее токсичными, ваш рейтинг (карма) была бы повыше.


            Вместо аргументов идет злоба, оскорбления. Это просто раздражает, не более того: никакой осмысленной позиции не вижу что-то.

              0
              Если бы ваши комменты были менее токсичными, ваш рейтинг (карма) была бы повыше.
              Если бы меня интересовала карма, я бы писал по другому.

              Вместо аргументов идет злоба, оскорбления
              Аргументация в моих коментах есть, просто вы ее игноируете

              не вижу что-то.
              Вы написали высосаную из пальца статью, про высосаную из пальца никому не нужную методологию, чтобы попиарить свой никому ненужный блог с 3.5 подписчиками и подкаст, который ведете чтобы набить плюсиков в популярность, чтобы подороже продаться.

              Достаточно аргументировано? Или назовете эти факты оскорблениями?

              А теперь вы пытаетесь сделать хорошую мину при плохой игре, но сказать вам особо нечего, что хорошо видно по вашему безжизненному комментарию
                –1
                Под аргументами я понимаю что-то связанное с сутью статьи: разработка через мутации. А не переходы на личности и выяснения, кто чей блог шатал.

                Такая неинтересная статья, такой неинтересный комент, ну так читайте интересные статьи и коменты.

                «Я три дня гналась за вами, чтобы сказать, как вы мне безразличны»
                  0
                  Под аргументами я понимаю
                  «Ваши пруфы не пруфы». Ну хорошо хоть не «сперва добейся»

                  Если вы вдруг забыли на какой комент отвечали, то напомню: эта ветка коментов не про вашу статью, а про моргенштернизацию (лел) ойти, частью которой вы являетесь. И именно об этом процессе я всю ветку говорю, а не о вашей статье — она нахрен никому не сдалась.

                  Хотите чтобы люди обсуждали ваши статью по сути, добавьте туда суть. Пока что там обсуждать нечего.

                  ну так читайте интересные статьи и коменты.
                  Если хотите чтобы вас не обсирали, не давайте повода для этого. А не указывайте людям что им делать.
                    –1
                    > Если хотите чтобы вас не обсирали, не давайте повода для этого.
                    Да мне в общем всё равно, это всего лишь коменты на хабре. Пишите что хотите. Просто удивляюсь такому живому интересу к неинтересному.

                    В целом теперь мне уже стало неинтересно обсуждать тут. Бессмысленный срач.
          0

          TDD — это очень тонкая методология, и она касается даже не процесса написания основного кода, а процесса создания новых фич. Причём, лучше всего оно работает для машиноориентированных фич. Пишешь тест под несуществующую фичу и в этот момент (будучи потребителем API) хорошо и плотно думаешь о том, как эту фичу сделать удобной (себе). Думаешь до того, как пишешь, что бесценно.

          +1

          Странный подход делать это руками когда есть инструменты Mutaition Testing для большинства популярных языков

            –1
            Честно говоря, сначала я тоже удивился такому подходу, когда читал оригинальную статью. Однако потом вспомнил один свой кейс.
            У меня был небольшой микросервис, который выполнял важную функцию, но бизнес-логики там было не очень много. Т.е. сервис дёргал 5 разных внешних API, и в зависимости от их ответов формировал своё заключение.

            Бизнес-логики — там было буквально пара-тройка методов, а всё остальное — бойлерплейт, который и тестировать то особо не надо: если бы там что-то пошло не так, это было бы видно в логах, и можно было бы просто откатить.

            Но при этом бизнес-логика наборот довольно важная, и ошибку там пришлось бы искать очень долго.

            При этом ради пары методов городить инструменты по всеобъемлющему мутационному тестированию ну особо не нет смысла. А так, вручную подёргав условия, можно было бы убедиться, что покрытие более менее достаточное.

            Т.е. это промежуточный, переходный этап перед тотальным подключением автоматического мутационного тестирования всего проекта
            0

            А что скажете по property base testing, как альтернативе mutation?

              0

              Mutation-testing руками, да ещё и в середине рабочего процесса — это глупость. Разумный метод — использование фреймворков мутации, причём мутационные тесты — это не часть продакшен-пайплайна, а отдельно стоящий пайплайн по таймеру или по наличию свободных ресурсов. У мутационного тестирования нет конца (т.к. это фаззинг с рандомом), есть только апериодическое сообщение о найденных потенциальных багах или плохо написанных тестах.

                0
                С академической точки зрения — концепция как концепция, со своими плюсами и минусами. Единственное, на мой взгляд, практическое применение — проекты, где ресурсы почти не ограничены, но требуется исключительная стабильность. Намного более девяти тысяч)
                Что интересно, этот подход можно совместить с отладкой разного рода багрепортов. Хоть как-то поднять отдачу.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое