Предыдущая серия была тут - http://18delphi.blogspot.com/2013/11/gui-2.html
Теперь хочется отметить вот что:
Я для себя выделяю несколько уровней для тестирования поведения компонент.
Разделяются они по тому - каким образом вызывается интересующий нас функционал.
Вот они:
1. Непосредственная посылка сообщения от мыши или клавиатуру.
2. Вызов Click или его аналогов непосредственно на интересующем нас контроле.
3. Вызов связанного TAction.
4. Вызов функционала бизнес-логики напрямую.
Каждый из перечисленных подходов - имеет право на жизнь и более того - служит для тестирования разных вещей.
"Непосредственная посылка сообщения от мыши или клавиатуру." - тестирует, что?
Это тестирует, что "реальный" ввод доходит до нашего контрола.
"Вызов OnClick или его аналогов непосредственно на интересующем нас контроле." - тестирует что?
Это тестирует, что у контрола определён метод Click и что он связан с нужной функциональностью.
"Вызов связанного TAction." - тестирует что?
Это тестирует тот факт, что в системе существует нужный TAction с нужной функциональностью. Пусть и не привязанной к контролам.
"Вызов функционала бизнес-логики напрямую." - тестирует что?
Это тестирует тот факт, что в системе есть нужная бизнес-логика, пусть и не привязанная к TAction или контролам, и что эта бизнес логика выполняется в соответствии с ТЗ.
Идея понятна? Надо приводить примеры?
Тут немного расшифрую.
Если есть подозрение, что "вообще бизнес-логика не работает", то надо тестировать её напрямую.
Если есть подозрение (или факты, косвенно подтверждаемые тем, что "по другой кнопке" - та же логика работает) что проблема в том, что контрол не обрабатывает ввод, то надо тестировать пункт 1 или пункт 2.
Что сказать про TAction? Когда его тестировать? Скорее всего тогда, когда TAction - доступен, а "Вызов функционала бизнес-логики напрямую." - либо недоступен, либо сложен в вызове.
Ну как-то так...
Теперь хочется отметить вот что:
Я для себя выделяю несколько уровней для тестирования поведения компонент.
Разделяются они по тому - каким образом вызывается интересующий нас функционал.
Вот они:
1. Непосредственная посылка сообщения от мыши или клавиатуру.
2. Вызов Click или его аналогов непосредственно на интересующем нас контроле.
3. Вызов связанного TAction.
4. Вызов функционала бизнес-логики напрямую.
Каждый из перечисленных подходов - имеет право на жизнь и более того - служит для тестирования разных вещей.
"Непосредственная посылка сообщения от мыши или клавиатуру." - тестирует, что?
Это тестирует, что "реальный" ввод доходит до нашего контрола.
"Вызов OnClick или его аналогов непосредственно на интересующем нас контроле." - тестирует что?
Это тестирует, что у контрола определён метод Click и что он связан с нужной функциональностью.
"Вызов связанного TAction." - тестирует что?
Это тестирует тот факт, что в системе существует нужный TAction с нужной функциональностью. Пусть и не привязанной к контролам.
"Вызов функционала бизнес-логики напрямую." - тестирует что?
Это тестирует тот факт, что в системе есть нужная бизнес-логика, пусть и не привязанная к TAction или контролам, и что эта бизнес логика выполняется в соответствии с ТЗ.
Идея понятна? Надо приводить примеры?
Тут немного расшифрую.
Если есть подозрение, что "вообще бизнес-логика не работает", то надо тестировать её напрямую.
Если есть подозрение (или факты, косвенно подтверждаемые тем, что "по другой кнопке" - та же логика работает) что проблема в том, что контрол не обрабатывает ввод, то надо тестировать пункт 1 или пункт 2.
Что сказать про TAction? Когда его тестировать? Скорее всего тогда, когда TAction - доступен, а "Вызов функционала бизнес-логики напрямую." - либо недоступен, либо сложен в вызове.
Ну как-то так...
Комментариев нет:
Отправить комментарий