Ich nehme an, die beste Antwort auf diese Frage würde auf der Notwendigkeit beruhen.
Bei meiner Arbeit trennen wir unseren Code/Testdaten von Umgebungstyp wie:
- -Test
- QA
- Staging
- Produktion
Bestimmte Umgebungen haben die gleichen Daten wie die Produktion, während andere ältere (oder völlig andere) Daten haben . Die Vorteile davon sind:
- Sandboxen zum Testen, Implementieren und "Spielen" mit neuen Ideen/Technologien.
- Sie haben keinen Einfluss auf die Live-Daten, die dem Kunden zur Verfügung stehen.
- Integrierte Tests können auf bestimmte Aspekte angewendet werden, die für die Hauptcodebasis agnostisch sind. Jetzt
, wie auf Ihre Fragen ... wie ich bereits erwähnt, ermöglicht die Trennung von Daten für uns zu schnell Änderungen vornehmen und neue Funktionen zu implementieren, da die Daten, die wir verwenden, um auf fokussiert ist, was wir testen. Wir haben drei Amtsleitungen, die alle über unabhängige Testdaten verfügen, die spezifisch für das sind, was getestet werden muss. Beim Testen der View haben wir eine Reihe von Tests, beim Testen der haben wir eine andere Reihe von Tests und beim Testen der Controller haben wir noch eine Reihe von Tests. Schließlich haben wir eine übergreifende Reihe von Integrationstests, die ausgeführt werden, wenn ein neuer Build veröffentlicht wird. In allen Fällen außer dem letzten leben die Tests mit der Komponente, für die sie erstellt wurden; Da es sich jedoch um Integrationstests handelt, ist es sinnvoll, dass sie getrennt von den drei Teilen, die sie verifizieren, aufbewahrt werden.
Ich denke, deine Idee ist solide.