Как грамотно построить архитектуру автотестов?

Всем доброго времени суток! Не первый раз слышу от многих (более опытных) коллег в сети, что нужно строить архитектуру автотестов так же как и архитектуру основного ПО, в том смысле, что (внезапно) автотесты - это точно такое же ПО (только более узкоспециализированное) и оно подвержено точно таким же проблемам и особенностям как и обычное ПО. Есть наиболее распространенные паттерны проектирования, такие как, например, PageObject'ы, DataProvider'ы, etc. Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?

храните тесты прямо рядом с тестируемым кодом, в соседних классах

а и, да, забыл сказать, что доступа к исходному коду тестируемого ПО нет (черный ящик), конечные UI сценарии

Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?

Если вообще нет доступа ни к исходному коду, ни к его создателям, то адекватного решения не будет.

 

Придётся не через N лет выбросить автотесты, а уже через N недель (повторять в цикле).

 

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

 

Это будет совершенно недоброе время суток, но без этого никак.

согласен, надо выбрасывать уже сейчас

 

и чем раньше, тем лучше

Всем доброго времени суток! Не первый раз слышу от многих (более опытных) коллег в сети, что нужно строить архитектуру автотестов так же как и архитектуру основного ПО, в том смысле, что (внезапно) автотесты - это точно такое же ПО (только более узкоспециализированное) и оно подвержено точно таким же проблемам и особенностям как и обычное ПО. Есть наиболее распространенные паттерны проектирования, такие как, например, PageObject'ы, DataProvider'ы, etc. Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?

 

Рассмотрим альтернативу выбрасыванию

Если ПО развивается, тесты придется развивать параллельно с ним. Тесты, работаюшие через N лет - это фантастика.

Чтобы тесты были поддерживаемы, разумеется, структуру надо делать по возможности простой, с небольшим числом уровней. Гиперсложную архитектуру тестов никто поддерживать не будет, даже разработчики.

А если по теме вопроса - "Как это всё более-менее грамотно построить", то этого не рассказать на форуме.

Читайте книги, например Р. Мартин "Чистый код" и "Чистая архитектура", и черпайте из них то, что кажется уместным для тестирования.

Вопрос очень общий, что могу порекомендовать:

https://www.youtube.com/watch?v=vrjN8VTeuOk

Также отличное видео про не только паттерны, но и какой должен быть фрейворк:

https://www.youtube.com/watch?v=EnooA2kEhY0

Видео почему-то норм не вставляются :(

Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?

В моей конторе разработчики не особо хотят что-либо делать ради удобства разработки и поддержки АТ. Получается что мои тестируемые проекты тоже в некоторой степени для меня черный ящик. По этому я выкручиваюсь следующим образом:

 

Изучив главные аспекты автоматизации, советую максимально избегать управления тестовыми данными через UI. Используй API например для авторизации или создания пререквезитов для теста. Уж к API у тебя всегда должен быть доступ и ты должен уметь написать запрос к серверу в твоем фреймворке для автоетстов. В моем случае такой подход упрощает мне поддержку и разработку тестов.