В нашей компании есть большое настольное приложение на основе Java, для которого мы создаем контрольные примеры.Мы хотим следовать подходу тестовой пирамиды следующим образом:
1) Мы просим разработчиков написать множество юнит-тестов (но не проверяем, где они написали юнит-тесты хорошего качества или нет).
2) Мы пишем сервисные тесты, где мы проходим каждую строку кода и пишем тесты Junit, чтобы протестировать все возможные методы и условия в коде.
3) Мы планируем создать тесты пользовательского интерфейса, чтобы обеспечитьПользовательский интерфейс работает правильно.
Я читал много блогов о подходе к тестовой пирамиде и понял, что нам следует тратить гораздо меньше времени на написание тестов пользовательского интерфейса, поскольку они плохо подходят для тестирования рентабельности инвестиций, поскольку обычно они занимают много времени.выполнить, и они хрупкие из-за их зависимости от элементов пользовательского интерфейса.Я абсолютно согласен с этими пунктами.
Но вопрос в том, что когда мы говорим, что нам нужно гораздо меньшее количество тестов пользовательского интерфейса, мы подразумеваем, что нам просто нужны тесты пользовательского интерфейса для случаев с приоритетом 1 (или тесты дыма)?Напротив, пользовательский интерфейс является элементом, с которым взаимодействует пользователь, поэтому не нужно ли нам в первую очередь убедиться, что он не сломан?Я имею в виду, когда мы говорим, что нам нужно сократить количество тестов пользовательского интерфейса, не повлияет ли это на качество доставки пользовательского интерфейса?Например, я написал множество сервисных тестов и убедился, что бэкэнд-бизнес-логика идеальна, но что, если пользовательский интерфейс испорчен?Разве это не одинаково важно?