Ответ
Да, ваши библиотеки тестирования GUI должны быть протестированы.
Например, если ваша библиотека предоставляет метод Check для проверки содержимого сетки по двумерному массиву, вы должны быть уверены, что она работает как задумано.
В противном случае ваши более сложные контрольные примеры, в которых проверяются бизнес-процессы, в которых сетка должна получать конкретные данные, могут быть ненадежными. Если ошибка в вашем Check методе дает ложные отрицания, вы быстро найдете проблему. Однако, если он дает ложные срабатывания, вас ждут серьезные головные боли.
Чтобы проверить CheckGrid метод:
- Заполнить сетку известными значениями
- Вызвать метод CheckGrid со значениями, заполненными
- Если этот случай проходит, работает хотя бы один аспект CheckGrid .
- Во втором случае вы ожидаете, что метод CheckGrid сообщит о сбое теста.
- Подробности того, как вы указываете ожидание, будут зависеть от вашей платформы xUnit (см. Пример позже). Но в принципе, если CheckGrid не сообщает о сбое теста, то сам тестовый случай должен завершиться неудачей.
- Наконец, вам может потребоваться еще несколько тестов для особых условий, таких как: пустые сетки, размер сетки, не соответствующий размеру массива.
Вы должны иметь возможность изменить следующий пример dunit для большинства фреймворков, чтобы проверить, что CheckGrid правильно обнаруживает ошибки:
begin
//Populate TheGrid
try
CheckGrid(<incorrect values>, TheGrid);
LFlagTestFailure := False;
except
on E: ETestFailure do
LFlagTestFailure := True;
end;
Check(LFlagTestFailure, 'CheckGrid method did not detect errors in grid content');
end;
Позвольте мне повторить: ваши библиотеки тестирования GUI должны быть протестированы; и дело в том - как вы делаете это эффективно?
Процесс TDD рекомендует вам сначала выяснить, как вы собираетесь тестировать новую функциональность до вы на самом деле реализуете его. Причина в том, что если вы этого не сделаете, вы часто ломаете голову о том, как вы собираетесь проверить, работает ли он. Крайне сложно переоборудовать контрольные примеры в существующие реализации.
Side Note
Одна вещь, которую вы сказали, немного беспокоит меня ... вы сказали, что "70% (вашего времени) поддерживаются (ваши тесты)"
Это звучит немного неправильно для меня, потому что в идеале ваши тесты должны быть простыми, и они должны изменяться только в случае изменения ваших интерфейсов или правил.
Возможно, я вас неправильно понял, но у меня сложилось впечатление, что вы не пишете "производственный" код. В противном случае вы должны лучше контролировать цикл переключения между тестовым кодом и рабочим кодом, чтобы уменьшить вашу проблему.
Некоторые предложения:
- Остерегайтесь недетерминированных значений. Например, даты и искусственные ключи могут нанести ущерб определенным тестам. Вам нужна четкая стратегия решения этой проблемы. (Другой ответ сам по себе.)
- Вам нужно будет тесно сотрудничать с «производственными разработчиками», чтобы обеспечить стабилизацию аспектов тестируемых интерфейсов. То есть Они должны знать, как ваши тесты идентифицируют компоненты GUI и взаимодействуют с ними, чтобы они не могли произвольно нарушить ваши тесты с изменениями, которые «не влияют на них».
- В предыдущем пункте было бы полезно запускать автоматические тесты всякий раз, когда они вносят изменения.
- Вам также следует остерегаться слишком большого количества тестов, которые просто сводятся к произвольным перестановкам. Например, если у каждого клиента есть категория A, B, C или D; затем 4 теста «Новый клиент» (по 1 для каждой категории) дают вам 3 дополнительных теста, которые на самом деле не говорят вам намного больше, чем первый, и которые «сложно» поддерживать.