Почему мы проверяем?
Когда я пишу тестирование на протяжении всего рабочего дня и сражаюсь с шутками, издевательствами и реагируя компоненты, я обнаруживаю, что размышляю над этим вопросом.
Какой смысл? Это для того, чтобы соответствовать какой -то произвольной метрике (90% или 100% тестовый охват), представленным менеджерами или старшими инженерами? Это для пользователя, так что у них есть лучший пользовательский опыт и меньше ошибок? Это для себя, кормить некоторые нарциссические тенденции и грандиозные идеи, которые вы лучший программист в мире?
Я единственный, кто получает дофаминовый порыв из этих маленьких зеленых точек?
В конечном итоге наиболее важным показателем для бизнеса является то, сколько денег сэкономлено путем написания тестов. Но сколько из нас, как инженеры, действительно хорошо понимают это?
Разработчики не заботятся об этом. Мало того, они так далеки от аспекта зарабатывания денег, что им невозможно хорошо понять это. У менеджера проекта может быть лучшее понимание, но они не те, которые пишут тесты. У них не будет достаточно хорошего понимания кодовой базы, чтобы Люди в бизнесе, которые понимают истинную стоимость вещей, не понимают программного обеспечения и то, как оно написано. Это одна из загадок трудовая специализация Анкет Мы становимся экспертами в нашем домене, но при этом скучаем по общей картине.
Так что, как узколобые инженеры, нам нужна лучшая причина, чем «сэкономить деньги». То, что мы можем понять и относиться к тому, что мы не слишком сужаются.
Мы должны проверить, чтобы сэкономить время разработчика.
Выслушайте меня. Время разработчика – это то, что у нас есть хорошее понимание (я знаю, некоторые из вас могут смеяться над этим). Разработчики понимают, какие функции могут сломаться и сколько времени займет для реализации. Время вашей команды не бесплатно, поэтому в большинстве случаев оно довольно сильно коррелирует с экономией денег вашей компании в любом случае. Тестирование, по сути, является инвестицией в будущий опыт развития вашей команды. Сохранение времени разработчика в конечном итоге является принципом в отношении сухого программирования, экстремального программирования (XP) и программирования Slurp. Хорошо, я сделал этот последний, есть слишком много глупых сокращений программирования.
Наше собственное время также лучше в качестве метрики в различных ситуациях и типах компании. Facebook и Google будут иметь совершенно разные варианты использования для тестов, чем небольшой стартап, который сойдет с земли. Функция разрыва в производстве для www.facebook.com вероятно, будет создавать волну тревожных колоколов, которые приводят к большой работе для разработчиков (он же $$$). Конечный к конечным тестам для продукта, который используется миллионами людей, поэтому гораздо более важнее, чем используется внутри, у нескольких сотрудников.
Но как приоритетное время разработчика помогает нам на самом деле писать лучшие тесты?
Давайте рассмотрим различные виды тестов и почему этот образ мышления может помочь вам:
Это должно быть самым быстрым для написания и должно дать нам уверенность в том, что отдельные части нашей системы работают, как мы предполагали. В конечном итоге они должны работать быстро, проверить свой собственный код (а не сторонние библиотеки) и служить документацией для будущих разработчиков. Они экономят время разработчика, облегчая рефакторинг и помогая на борту новых членов команды. Когда интеграционный тест неизбежно пройдет, вполне вероятно, что модульный тест может точно сказать вам, где и почему он не удался. Написание вокруг тестового интерфейса также продвигает хорошие кодовые практики, такие как использование Чистые функции и внедрение зависимости .
Мощные тесты должны быть достаточно быстрыми, чтобы вы могли использовать тесты для развития разработки (См. tdd ).
Несмотря на то, что вы можете и должны проходить модульные тесты как для Frontend, так и для бэкэнда, я считаю, что они имеют больше всего ценность в вашей бэкэнд -логике.
Они проверяют, как все взаимодействует в вашей системе. Интеграционные тесты сэкономили нам время, предотвращая разрыв общих вариантов использования по мере рефакторирования. Я склонен думать об этом как о большем количестве тестов на фронта, хотя они также могут быть на бэкэнд. Они также гораздо быстрее, чем вручную щелкнуть по многоэтапным формам, при условии, что они хорошо написаны. Интеграционные тесты могут по -прежнему использовать макет и дать нам больше гарантии (на единицу времени, затрачиваемого на их написание), чем модульные тесты, которые наша система работает, как ожидает пользователь.
Они проверяют, как ваша система взаимодействует в целом. Истинный тест на конечный и конечный, не имеет никаких макетов и проходит через ваше программное обеспечение так, чтобы реальные пользователи могли его использовать. Они имеют наибольшую ценность, но также являются наиболее сложными для бега и увлечения больше всего времени. Конечные тесты сэкономить время для разработчика, предотвращая нерабочее время о том, как выставление счетов снижается для всей компании. Возможно, истек срок службы вашего TLS или ваш единый поставщик регистрации. Черт возьми, Джон, я сказал тебе не трогать эти настройки.
Это не значит, что все Тесты хороши. Вы должны следить за плохими тестами, те, которые занимают время разработчика.
Примерами этого являются тесные тесты или те, которые слишком заботятся о деталях реализации. Вы должны постоянно спрашивать себя, чего я пытаюсь достичь с помощью этого теста? Я тестирую новую бизнес -логику, которая подвержена человеческой ошибке и рефактовам, или я тестирую, как работает существующая библиотека? Вам не нужно проверять React, Flask или Django, уже есть тысячи разработчиков, которые выполнили эту работу за вас.
Если тест потребуется вам пару дней, чтобы написать, уже в основном покрывается более простыми тестами и не охватывает реалистичные варианты использования, это хороший признак того, что это может не потребоваться.
Аналогичным образом, тест, который займет несколько секунд, чтобы запустить, потому что вы не издевались над какой -либо дорогой сторонней функцией, будет стоить времени для каждого разработчика. Для вас, как единственного разработчика, может иметь смысл написать этот тест, но теперь умножьте секунды, которые тест принимает x, сколько раз каждый разработчик запускает тестовый набор в день x количество разработчиков в вашей компании. Это быстро складывается.
Если ваши тесты записаны таким образом, что каждое небольшое изменение в кодовой базе требует рефакторирования теста (или более одного) без необходимости, это определенно не экономит времени. Это моя проблема с Тестирование снимка Анкет Такие тесты заставляют нас чувствовать себя «безопасными», но на самом деле они не экономят какое -то количество времени или делают наш код меньше, подверженным ошибкам.
Я думаю, что Гильермо попадает, так это то, что тесты могут стать грязными, а несколько хорошо продуманных из них дадут вам большую часть ваших результатов. Тесты, такие как программное обеспечение и многие другие области, как правило, следуют Принцип 80/20 Анкет 20% тестов в конечном итоге дадут вам 80% результатов. Не просто бездумно пишите тесты ради написания их, чтобы достичь некоторого произвольного номера покрытия, или потому, что вы видели изображение пирамиды, которая рассказывает вам, насколько важны модульные тесты.
Возьмите эти диаграммы с зерном соли
Вместо того, чтобы просить других инженеров всегда писать тесты, убедитесь, что они понимают Почему Они пишут их. 100% покрытие кода не означает, что он на 100% безопасен, у вас может быть плохой тест, который никогда не произойдет в реальности и считается, что он имеет 100% охват. Из личного опыта не хватает времени на разговор о том, как выглядят хорошие тесты.
Итак, кроме осознания, как мы используем эту концепцию, чтобы улучшить наше развитие? Благодаря последовательным обзорам и размышлениям о тестах, которые мы пишем. Создает ли кусок кода непропорциональный объем обслуживания для вас? Может быть, пришло время рефакторировать и написать для этого лучшие тесты.
Вместо того, чтобы сосредоточиться на бесполезных показателях или жестких правилах, тестирование следует рассматривать как постоянный процесс обучения/улучшения. Тесты должны уделять необходимое внимание к ним и не рассматриваться как граждане второго класса. Каждый должен тратить время на рефакторинг и пересмотр, отбрасывая те, которые не тестируют основные части вашего программного обеспечения, и улучшая медленные. Отказаться от следующего выхода и вместо этого проведите тестирование, это будет гораздо более продуктивным использованием времени разработчика.
Оригинал: “https://dev.to/g_abud/on-testing-2k0i”