LINUX.ORG.RU

История изменений

Исправление vostrik, (текущая версия) :

упирать нужно на функциональность в любом случае. разница между функциональным тестированием и регрессионным - только в том, когда оно проводится. во время разработки пишутся функциональные модульные тесты (давайте пользоваться этим термином, чтобы отделить например те тесты, которые пишутся в рамках TDD и собственно тестами не являются, от тех, которые в описываемой задаче) для проверки того, что заявленные функциональные требования выполнены, а во время регрессии они же исполняются для проверки того, что внесенные изменения на функциональность не повлияли.

в вашем примере ваша задача «доработать систему юнит-тестов» будет звучать как

Организовать фреймворк для выполнения тестов

Разобрать систему на минимальные модули, которые могут быть протестированы с использованием этого фреймворка

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

На основании требований покрыть функциональными модульными тестами все выделенные модули

Организовать фреймворк для генерации отчетов о тестировании

Организовать фреймворк для оценки покрытия когда в рамках выполнения тестов и убедиться, что покрытие не ниже требуемых значений

то, что этот фреймворк и тесты будут использоваться в рамках регрессионного тестирования - дело стопицотое

Исходная версия vostrik, :

NO

упирать нужно на функциональность в любом случае. разница между функциональным тестированием и регрессионным - только в том, когда оно проводится. во время разработки пишутся функциональные модульные тесты (давайте пользоваться этим термином, чтобы отделить например те тесты, которые пишутся в рамках TDD и собственно тестами не являются, от тех, которые в описываемой задаче) для проверки того, что заявленные функциональные требования выполнены, а во время регрессии они же исполняются для проверки того, что внесенные изменения на функциональность не повлияли.

в вашем примере ваша задача «доработать систему юнит-тестов» будет звучать как

Организовать фреймворк для выполнения тестов

Разобрать систему на минимальные модули, которые могут быть протестированы с использованием этого фреймворка

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

На основании требований покрыть модульными тестами все выделенные модули

Организовать фреймворк для генерации отчетов о тестировании

Организовать фреймворк для оценки покрытия когда в рамках выполнения тестов и убедиться, что покрытие не ниже требуемых значений

то, что этот фреймворк и тесты будут использоваться в рамках регрессионного тестирования - дело стопицотое