История изменений
Исправление
vostrik,
(текущая версия)
:
упирать нужно на функциональность в любом случае. разница между функциональным тестированием и регрессионным - только в том, когда оно проводится. во время разработки пишутся функциональные модульные тесты (давайте пользоваться этим термином, чтобы отделить например те тесты, которые пишутся в рамках TDD и собственно тестами не являются, от тех, которые в описываемой задаче) для проверки того, что заявленные функциональные требования выполнены, а во время регрессии они же исполняются для проверки того, что внесенные изменения на функциональность не повлияли.
в вашем примере ваша задача «доработать систему юнит-тестов» будет звучать как
Организовать фреймворк для выполнения тестов
Разобрать систему на минимальные модули, которые могут быть протестированы с использованием этого фреймворка
Определить требования к тестируемой системе и её отдельным модулям
На основании требований покрыть функциональными модульными тестами все выделенные модули
Организовать фреймворк для генерации отчетов о тестировании
Организовать фреймворк для оценки покрытия когда в рамках выполнения тестов и убедиться, что покрытие не ниже требуемых значений
то, что этот фреймворк и тесты будут использоваться в рамках регрессионного тестирования - дело стопицотое
Исходная версия
vostrik,
:
NO
упирать нужно на функциональность в любом случае. разница между функциональным тестированием и регрессионным - только в том, когда оно проводится. во время разработки пишутся функциональные модульные тесты (давайте пользоваться этим термином, чтобы отделить например те тесты, которые пишутся в рамках TDD и собственно тестами не являются, от тех, которые в описываемой задаче) для проверки того, что заявленные функциональные требования выполнены, а во время регрессии они же исполняются для проверки того, что внесенные изменения на функциональность не повлияли.
в вашем примере ваша задача «доработать систему юнит-тестов» будет звучать как
Организовать фреймворк для выполнения тестов
Разобрать систему на минимальные модули, которые могут быть протестированы с использованием этого фреймворка
Определить требования к тестируемой системе и её отдельным модулям
На основании требований покрыть модульными тестами все выделенные модули
Организовать фреймворк для генерации отчетов о тестировании
Организовать фреймворк для оценки покрытия когда в рамках выполнения тестов и убедиться, что покрытие не ниже требуемых значений
то, что этот фреймворк и тесты будут использоваться в рамках регрессионного тестирования - дело стопицотое