Аннотация В статье рассказывается о нетрадиционном, но полезном виде тестов, а также подводятся итоги семилетней работы по разработке тестов.
Зачем нужны тесты компонентов? В конце концов, существуют, скажем, модульные тесты, которые детально проверяют внутренности компонентов.
Они тщательно проверяют, что компонент работает так, как задумано разработчиком.
Но зачастую это проверка «пуговиц», а не того, как сидит костюм в целом.
И поведение, задуманное программистом, не всегда совпадает с тем, чего хотел заказчик.
А есть, например, приемочные испытания.
И они устраняют все эти недостатки.
Но, к сожалению, вводят новые.
Они медлительны, часто нестабильны и обычно ручны.
Однако они лишь указывают на проблему, но не локализуют ее.
Очевидно, это говорит о необходимости промежуточных тестов, которые станут золотой серединой между модульными и приемочными тестами.
Компонентные тесты могут стать этой золотой серединой.
Что такое компонентные тесты? Это тесты публичного API компонента.
Соответственно, они написаны на том же языке, что и компонент. Цель теста:
- проверить соответствие компонента своим контрактам
- проверить соответствие требованиям
Последнее особенно важно, поскольку Unit-тесты обычно пишутся исходя из ожиданий разработчика, но здесь необходимо проверить ожидания клиента.
Например, динамическая библиотека или COM-объект. Тогда компонентные тесты дадут максимальный эффект. Плюсы k-тестов:
- Придает стабильность развитию.
Очевидно, что комплексная проверка публичных интерфейсов позволяет сохранить компонент в более-менее работоспособном виде. - Точно локализовать проблемы.
Даже если сам тест компонента довольно общий, его всегда можно глубоко отладить, быстро дойдя до производственного кода.В этом случае тестовая среда будет минимальной и настроенной автоматически.
- Ускорьте разработку при критическом количестве разработчиков.
Известно, что программисты подобны лошадям.Если одна лошадь тянет телегу мощностью 1 л.
с.
с.
, то тянут восемь лошадей мощностью всего около 4 л.
с.
С.
Аналогично, добавление в команду еще одного разработчика (особенно в конце проекта) часто не только не ускоряет его, но и замедляет. Тогда как добавление разработчика тестов компонентов — это всегда плюс, поскольку он действует относительно независимо от команды: делает (по сути внешние) тесты, ускоряет сборку, оптимизирует файлы сборки и т. д.
- Уточните (а затем проверьте) требования клиентов.
Поскольку разработчик компонентного теста не привязан к реализации, он менее подвержен эффекту «я знаю, как это сделать сам».В случае неоднозначного требования рядовой разработчик склонен делать то, что удобнее (интереснее, быстрее, проще).
Тогда как разработчик КТ в данном случае склонен уточнять, чего именно ожидает заказчик.
- Относительно стабильный и относительно быстрый (по сравнению с ручными тестами и автоматическими тестами через пользовательский интерфейс).
- Время для развития и поддержки.
Очевидно, что альфа-версия продукта, если часть времени будет потрачена на написание компонентных тестов, появится позже.Будет ли победа в целом? Релиз выйдет раньше? Это хороший вопрос.
Мое мнение: при разработке с компонентными тестами релиз выйдет примерно в те же сроки.
Но с меньшей спешкой и более предсказуемым временем.
Время разработки естественным образом увеличится, время исправления ошибок и стабилизации сократится.
Поскольку вторая часть гораздо менее предсказуема, ее сокращение благотворно скажется на объеме обработки и хлопот. Однако это всего лишь мой опыт, и реальность может быть другой.
Вполне возможно, что время, отведенное на тестирование компонентов, будет потрачено на дублирование существующих модульных тестов.
- Меньше взаимозаменяемости.
Разделение ролей повышает эффективность, но снижает взаимозаменяемость.Разработчики редко стремятся глубоко вникать в тесты компонентов, которые могут иметь (или моделировать) довольно сложную среду.
Разработчики компонентных тестов недостаточно хорошо знают производственный код, чтобы легко его редактировать.
- Раздражающее дублирование.
При хороших модульных тестах тесты компонентов часто оказываются избыточными.Это одновременно раздражает и ставит под сомнение их необходимость.
Координация планов тестирования модулей и компонентов помогает, но полностью исключить дублирование обычно не удается.
- Необходимость соблюдать правильный рабочий процесс.
Когда требования получены, задача должна быть назначена как разработчику, так и составителю тестов.Затем они заканчивают работу примерно в одно и то же время.
Компонент прогоняется тестами, ошибки оперативно выявляются и исправляются, и на выходе получается более-менее готовый продукт. В этом случае польза от компонентных тестов максимальна.
Но часто бывает, что сроки давно сорваны, все бросают писать только код, а компонент отправляется на ручное тестирование без тестов.
И только потом приглашают разработчика тестов — мол, нехорошо, что код выпускают без тестов, их надо добавить.
При этом большая часть ошибок обнаруживается ручными тестировщиками, разработчики вносят исправления вслепую (или сами проверяют правки вручную), а тесты, написанные постфактум, находят лишь небольшое количество ошибок (что негативно влияет на моральный дух их автора).
).
Такое использование компонентных тестов в лучшем случае бесполезно, и от него трудно защититься.
- Мало подходящих людей.
Разработчик тестов компонентов должен, с одной стороны, уметь писать код на языке компонента (а это, например, C++).Более того, если среда запуска компонента обширна, код может оказаться достаточно сложным.
С другой стороны, уметь скрупулезно тестировать чужие работы.
Таких людей не очень много, и они обычно сразу идут в разработку.
Но все же такие люди есть, и о них следующая часть.
Каково быть SDET? Очевидно, что SDET — инженер-разработчик программного обеспечения в тестировании — является идеальным кандидатом для написания компонентных тестов.
Он умеет писать код и умеет думать в тестах.
Он также предоставляет второе мнение, что также улучшает качество тестов и кода.
Все это звучит интересно и заманчиво – возможно, вы уже хотите им стать.
Здесь я кратко объясню, чем отличается работа СДЭТ от работы чистого разработчика.
Преимущества работы в компании СДЭТ:
- Новый код. SDET почти всегда пишет тесты с нуля.
И довольно часто окружение пишется с нуля.
Это очень красиво и дает большой простор для творчества.
- Низкая зависимость от устаревшего кода.
Каким бы ужасным ни был боевой код, тесты для него можно сделать грамотно и красиво.Конечно, плохо спроектированный код дает уродливые тесты, но их все равно можно сделать на порядок лучше, чем сам код.
- Более частый рефакторинг.
Изменения в тестах гораздо менее опасны, поэтому люди чаще на них соглашаются.Это хорошая возможность поработать над ошибками и попрактиковаться в написании чистого кода посредством рефакторинга.
- Развитие критического мышления.
Автотесты — это интересный поиск того, как взломать чужой код. Причем искать не тупо, не сидя и тыкая, а с помощью логики, комбинаторики и умения видеть уязвимости.Плюс, однажды созданный, чек продолжит у вас работать постоянно.
- Развитие умения тестировать код. Во время тренировок по рукопашному бою часто делают вступительные слова: «теперь работаем только ногами; теперь мы работаем только головой».
Использование всего одного механизма (в нашем случае автотестов) позволяет отточить его до мастерства.
- Меньше срочной работы.
SDET уделяет гораздо меньше внимания по выходным.Им не придется срочно ехать на работу, чтобы исправить критические ошибки.
Что ж, их шанс совершить серьезную ошибку гораздо ниже.
- Низкая сложность кодирования.
Тестовый код обычно проще производственного.Предусловия, вызов боевого кода, постусловия — и повторяем это для каждого теста.
Код создания окружения сложнее, но до боевого все равно не дотягивает. Выбор оптимальных алгоритмов, проектирование сложных структур данных, построение иерархий классов — обычно все это проходит мимо разработчика тестов.
- Медленный набор опыта .
Разнообразие и сложность ситуаций, в которых оказывается разработчик тестов, гораздо меньше.
Сбой на конвейере, красные тесты, иногда дамп — это основной набор вещей, с которыми обычно приходится работать.
Для разработчика сложность задач гораздо выше: начиная от вариаций компоновки и сборки, продолжая глюками под конкретного заказчика и хитрыми дампами, заканчивая поиском ошибок в компиляторе и сторонних библиотеках.
Да и не только.
- Серьезная разница в стиле тестирования с разработчиками.
Обычно SDET предпочитают компактные экспрессивные тесты, позволяющие создать сложную среду всего за несколько строк, и атомарные проверки в стиле равно/не равно (то есть выполняется требование или нет).Иногда он даже достигает собственного DSL. Просто разработчики предпочитают тесты с мелкодетальной настройкой окружения и многочисленными проверками различных аспектов поведения программы, что приводит к достаточно многострочным тестам.
Иногда дело даже доходит до копипаста (что в данном случае не считают грехом даже лучшие разработчики).
Здесь можно долго спорить, что лучше, или даже написать отдельную статью, но дело в том, что когда разработчик пытается модифицировать SDET-тесты (или наоборот), это часто приводит к долгим и неэффективным дискуссиям.
- Ниже указана «оценка».
Возможно, из-за более простого кода и меньшей ответственности, но в конечном итоге это не имеет значения.Обычно так бывает.
- Переход на новую должность происходит сложнее.
В SDET вполне может возникнуть вопрос: вы так долго пишете тесты, то есть по сути просто вызываете функции и сравниваете результаты — вы умеете писать реальный код? Знаете ли вы все подводные камни языка? Решали ли вы сложные задачи? Вам когда-нибудь приходилось разбирать сложные ошибки или дампы? Есть ли у вас опыт работы с многопоточностью? У тебя наконец появились амбиции?
Я настоятельно рекомендую провести хотя бы год или два с SDET. Это очень полезный опыт для любого разработчика.
Но, на мой взгляд, оставаться там не стоит. Теги: #tdd #sdet #testing #компонентные тесты #юнит-тесты #разработчик тестов #тестирование ИТ-систем #tdd #Промышленное программирование #Карьера в ИТ-индустрии
-
Дельта
19 Oct, 24 -
Важные Нюансы «Компьютерной Помощи»
19 Oct, 24 -
Введите Все
19 Oct, 24 -
Приложение Extjs/Rails Crud За 7 Минут
19 Oct, 24 -
Мультизагрузка Файлов, Версия N
19 Oct, 24 -
Здесь Будут Драконы
19 Oct, 24 -
Кнопка Сброса Для Слепых
19 Oct, 24
