Десять лет назад мы знали только о приемочных тестах. В последнее десятилетие произошел гигантский скачок вперед: он принес модульное тестирование. Модульное тестирование стало популярным благодаря JUnit . В свою очередь, TestNG добавил аннотации к тестовым классам, делая их еще проще. Затем EasyMock предоставил средства для имитации наших зависимостей классов в тестовом контексте, в то время как Mockito упростил процесс этого. Можно подумать, что все было сказано и сделано для модульного тестирования, и мы должны двигаться вперед к более достойной цели нашей рабочей силы.
Я думаю, что ничто не может быть дальше от истины. Я думаю, что следующим шагом будет сделать тесты более ремонтопригодными. В течение моей карьеры мне приходилось поддерживать программное обеспечение, в котором не было модульных тестов, и это было плохо. Однако, когда мне приходилось работать с программным обеспечением с помощью тестов, мне было трудно понять, я не могу точно сказать, было ли это лучше. Требуется время, чтобы убедиться, что нет регрессии и побочных эффектов, это одно, а время для отладки сложностей теста — совсем другое, и руководство вряд ли этого ожидает. Одно конкретное препятствие заключается в утверждении утверждения. Я понимаю, это может показаться странным на первый взгляд. Как в мире следующее утверждение может быть неразрешимым?
Assert.assertFalse(myList.isEmpty());
Что ж, я делаю вывод, что некоторым людям должно быть достаточно всегда писать одни и те же утверждения и предоставлять какой-то общий API для их проверки. FEST и Hamcrest являются примерами таких продуктов тестирования, которые позволяют нам повысить нашу производительность за счет использования DSL, где домен является утверждением. Оставив все это, я не мог больше согласиться с их использованием и даже продвигать его в своих командах. Тем не менее, Hamcrest также предоставляет API для создания собственного настраиваемого сопоставителя: хотя создание такого сопоставителя может показаться полезным на первый взгляд, я попытаюсь поднять некоторые моменты против него.
Во-первых, как насчет ремонтопригодности? Если тест не пройден после того, как я сделал обновления, это из-за моего кода, совпадения или их комбинации? Мне придется либо спросить у исходного кодера, но в большинстве случаев я сам буду решать такие вещи. Это, вероятно, будет связано с потом, трудом и большой отладкой. В отдельности стоимость невелика, но она экспоненциально пропорциональна количеству совпадений.
Затем, чтобы уменьшить вероятность ошибки в сопоставителе, она должна быть проверена самостоятельно! Будут ли их соответствующие тесты требовать сопоставления утверждений? Кажется, что это будут черепахи до дна. Опять же, расходы неизбежно возрастут.
Более того, в школе нас учат, что дублирование кода — это плохо (многие инструменты предоставляют этот показатель), и его следует избегать любой ценой. Я могу поддержать только первую аксиому, точно так же, как я должен осудить вторую и, в частности, часть «любой ценой». Это не правда! Дублирование — это первый уровень повторного использования, и я надеюсь, что предыдущие аргументы указывали на стоимость написания и поддержки пользовательских сопоставлений. Например, если мы дублируем две строки три раза, этого недостаточно, чтобы оправдать добавленную стоимость сопоставителя!
Наконец, это может показаться странным, но тестирование — не цель программного обеспечения , а лишь средство для достижения цели (о чем я должен написать в следующем посте). Мы не ставим задачу сделать наше резюме ярче или принять участие в соревнованиях с самым высоким охватом кода. Нам платят только за то, что мы поставляем программное обеспечение нашим клиентам, соблюдая при этом святую троицу затрат, задержек и качества. Если написание пользовательских сопоставлений может помочь нам достичь этой цели, хорошо, но действительно ли это так, очень контекстуально.
В настоящее время мне кажется выгодным писать пользовательские сопоставления при следующих обстоятельствах:
- В этом есть реальное преимущество. Поиск, сколько существует дублированных строк и является ли экономически эффективным их факторизация в сопоставлении.
- Это не повлияет на доставку. Что произойдет, если мы находимся в процессе написания лучшего из когда-либо найденных совпадений и нам приказано отправить продукт? Заказчик не заботится о матчах.
- Совпадения никогда не должны принадлежать одному разработчику, а всей команде. Это предотвращает или, по крайней мере, уменьшает риск отладки средства сравнения, чтобы понять его цель.
В заключение, я надеюсь, что эта статья заставила вас задуматься обо всем этом. В следующий раз, когда вы собираетесь создать средство сравнения, подумайте об этом: возможно, это хорошая вещь, но это не обязательно так.