среда, 6 ноября 2013 г.

GUI-тестирование "по-русски". Заметка об уровнях тестирования

Предыдущая серия была тут - http://18delphi.blogspot.com/2013/11/gui-2.html

Теперь хочется отметить вот что:

Я для себя выделяю несколько уровней для тестирования поведения компонент.

Разделяются они по тому - каким образом вызывается интересующий нас функционал.

Вот они:
1. Непосредственная посылка сообщения от мыши или клавиатуру.
2. Вызов Click или его аналогов непосредственно на интересующем нас контроле.
3. Вызов связанного TAction.
4. Вызов функционала бизнес-логики напрямую.

Каждый из перечисленных подходов - имеет право на жизнь и более того - служит для тестирования разных вещей.

"Непосредственная посылка сообщения от мыши или клавиатуру." - тестирует, что?
Это тестирует, что "реальный" ввод доходит до нашего контрола.

"Вызов OnClick или его аналогов непосредственно на интересующем нас контроле." - тестирует что?
Это тестирует, что у контрола определён метод Click и что он связан с нужной функциональностью.

"Вызов связанного TAction." - тестирует что?
Это тестирует тот факт, что в системе существует нужный TAction с нужной функциональностью. Пусть и не привязанной к контролам.

"Вызов функционала бизнес-логики напрямую." - тестирует что?
Это тестирует тот факт, что в системе есть нужная бизнес-логика, пусть и не привязанная к TAction или контролам, и что эта бизнес логика выполняется в соответствии с ТЗ.

Идея понятна? Надо приводить примеры?

Тут немного расшифрую.

Если есть подозрение, что "вообще бизнес-логика не работает", то надо тестировать её напрямую.

Если есть подозрение (или факты, косвенно подтверждаемые тем, что "по другой кнопке" - та же логика работает) что проблема в том, что контрол не обрабатывает ввод, то надо тестировать пункт 1 или пункт 2.

Что сказать про TAction? Когда его тестировать? Скорее всего тогда, когда TAction - доступен, а "Вызов функционала бизнес-логики напрямую." - либо недоступен, либо сложен в вызове.

Ну как-то так...

Комментариев нет:

Отправить комментарий