Я полагаю, что лучший ответ на этот вопрос будет основан на необходимости.
В моей работе, выделим наши данные кода/тест по типу среды как:
- Тест
- QA
- Балетмейстер
- Производство
Некоторые среды имеют те же данные, что и производство, тогда как другие имеют более старые (или совершенно разные) данные , Преимущества этого:
- Песочницы для тестирования, реализации и «игры» с новыми идеями/технологиями.
- Вы не влияете на живые данные, обращенные к клиенту.
- Интегрированные тесты могут быть удовлетворены/сфокусированы на определенных аспектах, которые являются агностическими для основной базы кода.
Теперь, что касается ваших вопросов ... как я уже говорил выше, разделение данных позволяет нам быстро вносить изменения и реализовать новые возможности, так как данные, которые мы используем сфокусирован на то, что мы тестируем. У нас есть три соединительных линии, которые имеют независимые тестовые данные, которые являются специфическими для того, что нужно протестировать. При тестировании View у нас есть набор тестов, при тестировании Model у нас есть еще один набор тестов, и при тестировании Controller у нас есть еще один набор тестов. Наконец, у нас есть сложный набор интеграционных тестов, которые запускаются при выпуске новой сборки. Во всех случаях, кроме последнего, тесты соответствуют компоненту, для которого они созданы; но опять же, поскольку они являются интеграционными тестами, имеет смысл, что они хранятся отдельно от трех частей, которые они проверяют.
Я думаю, что ваша идея прочная.