Привет! Меня зовут Артём, и я занимаюсь автоматизацией тестирования. Антипаттерны в разработке — довольно популярная тема. Но ведь в тестировании тоже есть свои "плохие советы", и они довольно забавно пересекаются с разработкой. Недавно мне на глаза попалась ироничная статья про антипаттерны в тестировании. Вашему вниманию!
Мы стараемся как можно скорее доказать, что неправы, потому что только таким образом можем развиваться.
Ричард Фейнман
Есть много способов усложнить жизнь командам автоматизации тестирования. Если вы разработчик или системный архитектор, и недолюбливаете кого-то из тестировщиков, то эта статья — для вас. Вы найдете в ней сокровенное знание, вдохновившись которым, вы научитесь делать интерфейс любого приложения практически непригодным для тестирования.
Ну, а если вы добрая душа и уважительно относитесь к чужому труду, то можете рассматривать эту статью как набор антипаттернов.
Итак, поехали.
Сборник проклятий
Идентификация
Самая первая ваша задача — сделать идентификацию элементов интерфейса чересчур трудной или совершенно невозможной.
Эмпирическое правило: никаких ID.
Никогда не присваивайте элементам интерфейса какие-либо ID. C их помощью инструментам автоматизированного тестирования проще всего находить элементы. Кроме того, даже при изменении макета интерфейса ID сохраняются и позволяют находить элементы. А вот без ID тестирование наверняка провалится.
Динамические ID
Если вы не можете избавиться от ID, то хотя бы сделайте их динамическими. Генерируйте новое значение при каждом отображении представления (view) пользователю. И тогда все тесты, использующие фиксированные значения ID, будут автоматически сломаны сразу же после записи.
Динамический заголовок приложения
Это прекрасная идея — добавлять время в главный заголовок окна приложения. Например:
Platinum CRM - ACME - December 19, 02:46:23 pm
Эта методика может усложнить не только определение элементов интерфейса, но и процесс записи теста. Представьте, что объекты внутри инструмента автоматизированного тестирования группируются по заголовку окна — тогда каждый объект превратится в отдельную группу.
Время выполнения
При обновлении данных длительность открытия диалога или загрузки страницы может быть непредсказуемой. Это заставит инженеров по автоматизации использовать в тестах много выражений синхронизации.
Подождите! Есть и другие способы сделать время выполнения совершенно случайным.
Неэффективная реализация обработки данных
Это очень просто. При реализации ПО не думайте об объеме данных, проверяйте код с помощью маленьких баз данных и в одном-единственном окружении. Гарантирую, что при реальной нагрузке ваша программа будет отвечать медленно.
Развёртывание во враждебной среде
Разверните серверную часть своего решения в виртуальной машине, которая на сервере с кучей других ВМ. Есть большая вероятность, что эти соседние ВМ заберут ресурсы процессора/памяти/диска, когда они вам больше всего нужны.
Вспомогательные API
Никогда не реализуйте в своём приложении интерфейсы доступа вроде UI Automation и ARIA, иначе у тестировщиков будет эффективный способ автоматизации взаимодействия с приложением. Вы просто не имеете права давать им такую власть.
Почаще обновляйте макет интерфейса
Меняйте макет каждую неделю. Вместе с вышеприведёнными советами это просто убьёт тестировщиков. Возможно, они даже начнут фантазировать о ручном тестировании, потому что в этом случае они не будут видеть результаты своей работы лежащими в руинах.
Не давайте им шансов
Состояние приложения
Ваше приложение не должно никак показывать своё текущее состояние и что оно делает. Не разглашайте ничего, что можно использовать для понимания происходящего или проверки корректности поведения приложения. Никаких панелей состояния, никаких навигационных цепочек. Не давайте возможности понять, что приложение сейчас чем-то занято.
Навигация с помощью клавиатуры
Приложение не должно поддерживать альтернативные способы навигации или взаимодействия, вроде сочетаний клавиш. Хотите перемещаться по меню? Мышь и только мышь. Хотите перейти к другой ячейке? Только мышь, стрелки на клавиатуре работать не должны. Короче, вы поняли суть.
Логи
Не пишите никаких логов. Они могут дать информацию о проблемах и содержать подсказки к их исправлению.
Кнопки с иконками
Используйте кнопки с иконками и ни при каких обстоятельствах не делайте подписи или текстовые подсказки для кнопок. В сочетании с отсутствием ID это сделает идентификацию почти невозможной или очень ненадёжной.
В заключение
Помните! Чтобы превратить тестирование интерфейса в кошмар, нужно следовать базовым принципам:
- Сделать ненадёжной идентификацию объектов.
- Сделать непредсказуемым поведение приложения.
- Изменять интерфейс так, чтобы это ломало тесты и превращало их в мусор.
- Приложение должно быть чёрным ящиком для инструментов автоматизированного тестирования.
- Эффективно пресекайте любые попытки обходов, вроде сочетаний клавиш или анализа логов.
И наконец, если тестировщики попросят сделать что-то, противоречащее этим советам, просто игнорируйте.
Удачи!
Автор: bbidox
