Przypuszczam, że najlepsza odpowiedź na to pytanie byłaby oparta na potrzebie.
W mojej pracy możemy segregować nasze dane Kod/test od rodzaju środowiska jak:
- test
- QA
- Staging
- Produkcja
Pewne środowiska mają te same dane, co produkcja, podczas gdy inne mają starsze (lub zupełnie inne) dane . Korzyści z tego są następujące:
- Piaskownice do testowania, wdrażania i "zabawy" z nowymi pomysłami/technologiami.
- Nie wpływasz na żywe dane skierowane do klienta.
- Zintegrowane testy mogą być ukierunkowane na/skoncentrowane na pewnych aspektach, które są agnostyczne dla głównej podstawy kodu.
Teraz, jak na swoje pytania ... jak już wspomniano powyżej, segregacja danych pozwala nam na szybkie wprowadzanie zmian i wdrażanie nowych funkcji, ponieważ dane używamy koncentruje się na co testujemy. Mamy trzy pnie, z których wszystkie mają niezależne dane testowe, które są specyficzne dla tego, co należy przetestować. Podczas testowania View mamy zestaw testów, podczas testowania Model mamy inny zestaw testów i podczas testowania Controller mamy kolejny zestaw testów. Wreszcie mamy zestaw testów integracyjnych, które są uruchamiane po wydaniu nowej wersji. We wszystkich przypadkach, z wyjątkiem ostatniego, testy odbywają się z komponentem, dla którego zostały stworzone; ale znowu, ponieważ są to testy integracyjne, ma sens, że są trzymane oddzielnie od trzech części, które sprawdzają.
Myślę, że twój pomysł jest solidny.