Какова же их цель? Я имею в виду, в каком состоянии я должен выполнять каждый из них?
как для условия примера. если у вас есть сервер бэкэнд и несколько интерфейсных веб-сайтов, какой из них вы сделаете? Сначала выполните тестирование сервера бэкэнда или выполните тестирование UI в веб-интерфейсе? при условии, что сервер и интерфейсные веб-сайты уже существуют, поэтому это не итеративный дизайн для построения вместе с (TDD)...
Модульное тестирование направлено на тестирование небольших частей вашего кода (отдельных классов/методов) в отрыве от остального мира.
UI-тестирование может быть другим названием для системного/функционального/приемочного тестирования, когда вы тестируете всю систему вместе, чтобы убедиться, что она делает то, что должна делать в реальных условиях. (Если под тестированием пользовательского интерфейса вы не подразумеваете тестирование удобства использования, внешнего вида и т.д., Которое обычно ограничено деталями пользовательского интерфейса.)
Они необходимы в большинстве проектов, но в разное время: модульное тестирование во время разработки (в идеале с самого начала, стиль TDD) и тестирование пользовательского интерфейса несколько позже, когда у вас действительно будет законченный функциональность для тестирования.
Если у вас уже работает система, но нет тестов, практически у вас есть устаревший код. Стремитесь получить наилучшее тестовое покрытие, достижимое с наименьшими усилиями, что означает функциональные тесты высокого уровня. Добавление юнит-тестов тоже необходимо, но это требует гораздо больше усилий и начинает окупаться позже.
Рекомендуемое чтение: Эффективная работа с устаревшим кодом.
Unit test всегда должно быть выполнено. Unittests предоставляют доказательства того, что каждый UNIT (read: object) вашего технического решения обеспечивает ожидаемые результаты. Чтобы это было очень (возможно, слишком) просто, пользовательское тестирование проверяет, соответствует ли ваша система потребностям и требованиям пользователя.
Тестовая пирамида [1] является важной концепцией, хорошо описанной Мартином Фаулером. Короче говоря, тесты, которые запускаются сквозным через пользовательский интерфейс, являются хрупкими и дорогими в написании. Вы можете использовать тестовые инструменты записи [2] для ускорения записи и повторной записи. Отказ от ответственности - я разработчик такого инструмента.
[1] https://martinfowler.com/articles/practical-test-pyramid.html
В дополнение к принятому ответу, сегодня я только что задал вопрос, почему бы не просто программно вызывать функции макета, а затем тестировать свою логику вокруг этого?
Ответ, который я получил от старшего разработчика, был следующим: программно запускать функции макета не будет абсолютной копией реального пользовательского опыта. В реальном мире система вызовет множество обратных вызовов, например, когда пользователь приложения работает на переднем плане или на переднем плане. Очевидно, что вы можете запускать такие события вручную и тестировать снова, но вы были бы уверены, что все события во всех последовательностях были правильными?!
Реальный пользовательский опыт - это тот, где пользователь совершает реальные сетевые вызовы, нажимает на экраны, загружает несколько экранов друг на друга, и иногда вы можете получить системные обратные вызовы. Обратные вызовы, над которыми вы забыли издеваться, которые вы не правильно высмеяли. В юнит-тестах вы в основном тестируете изолированно. В тесте пользовательского интерфейса вы настраиваете приложение, может потребоваться войти в систему и т.д. Этот стек гораздо сложнее, чем unit тест. Следовательно, лучше не смешивать юнит-тестирование с UI-тестированием.