Kapitel 7. Best Practices

Inhaltsverzeichnis

7.1. Checkerberry test center
7.1.1. Namenskonvention
7.2. Checkerberry db
7.2.1. Good setup don't need cleanup
7.2.2. Mindestens ein Datenbankschema pro Entwickler
7.2.3. Vermeide das Testdaten-Labyrinth
7.2.4. Tests müssen unabhängig voneinander sein
7.2.5. Testdaten so groß wie nötig, so klein wie möglich
7.2.6. Lagere Caching-Daten in Includes aus
7.2.7. Verwende fachliche Lookup-Keys
7.2.8. Datenbank-Sequences mit Puffer verwenden
7.3. Checkerberry web
7.3.1. Anwendungsspezifische Modellschicht
7.3.2. Bevorzugter Locator: HTML-ID
7.3.3. Ermittlung der Locatoren
7.4. Checkerberry cockpit
7.4.1. Erstellung von Sicherungskopien
7.4.2. Angabe von Mapping-Informationen

7.1. Checkerberry test center

7.1.1. Namenskonvention

Bei der Verwendung des checkerberry test centers hat sich gezeigt, dass die Einhaltung einer Namenskonvention sinnvoll ist. Die Namenskonvention dient zur Markierung und Gruppierung verschiedener Tests. Dies ist vor allem dann sinnvoll, wenn die Tests zu unterschiedlichen Zeitpunkten ausgeführt werden sollen. Dies kann aus unterschiedlichen Gründen sinnvoll sein. Zum einen benötigen die Tests des checkerberry test centers bestimmte Voraussetzungen (Datenbank oder laufende Web-Anwendung), die nicht zu jedem Zeitpunkt erfüllt sind. Zum anderen kann die Laufzeit der Tests zu lang sein, sodass diese Tests z.B. nur nachts ausgeführt werden.

Für die Tests mit checkerberry db wird die Namenskonvention XXXIntegrationTest verwendet, während die Tests mit checkerberry web der Namenskonvention XXXGuiTest folgen.