Evgenii163

В джаве пишется класс-менеджер тестовых данных. 

А какие-нибуль библиотеки используются или самописный класс?

Спасибо за уделенное время и идеи!

API тесты это слишком высокий уровень, от этого и проблемы

 

проверяйте все что надо юнит-тестами, и поднимайтесь на уровень выше только когда это действительно нужно

 

 

Как понять что какой-то уровень системы достаточно покрыт такого уровня тестами? Я так понимаю для этого как раз и существуют системы, которые измеряют test coverege?
И еще как понять на каком уровне находится функционал системы? Путем того как и где это функционал используется?

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

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

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

 

ну ведь Сайпрессу надо будет поднять браузер и загрузить целую страницу, чтобы потом тест проверил только этот один компонент - ведь это намного дольше и более хрупко чем компонентный тест, очень много зависимостей

 

Согласен. Но так и не понял, равноценно ли диспатчить action компонентному тесту, и как это определить?