Antwoord.

Goede versiebeheer en integratie van geautomatiseerde tests zijn cruciaal om ervoor te zorgen dat de controle overeenkomt met de actuele status van het project.

Geschiedenis van de kwestie

Aanvankelijk werden geautomatiseerde tests vaak apart van het hoofdproject uitgevoerd, wat leidde tot incompatibiliteiten en onderhoudsproblemen. De ontwikkeling van meerdere takken, frequente software- en testreleases – hebben de noodzaak van een gemeenschappelijk versiecontrolesysteem gecreëerd.

Probleem

Zonder versiebeheer en gecoördineerde integratie ontstaan er:

Het uitvoeren van verouderde tests op gewijzigde software
"Breuken" van tests bij de release van nieuwe functionaliteiten, die geen rekening houden met wijzigingen in de tests
Fouten in CI/CD

Oplossing

De moderne benadering:

Tests worden opgeslagen in een gezamenlijk versiecontrolesysteem (meestal git)
Koppeling van de testtak aan de ontwikkeltaak van de software: in de feature-tak gaan tests en code samen
Automatische controles/bouwingen worden uitgevoerd op pull requests
Review en goedkeuring van wijzigingen in tests en code

# Algemene aanpak:
git checkout -b feature/new_login
# Functie en tests worden samen ontwikkeld en getest
# Na de review worden ze samen samengevoegd in de hoofdvertak

Belangrijke kenmerken:

Overeenstemming tussen de wijzigingen in de code en de tests (geen desynchronisatie)
Gemakkelijke terugrol en versievergelijking (via git history)
Mogelijkheid voor samenwerking en code review van geautomatiseerde tests

Lastige vragen.

Kunnen tests in een aparte (van de projectcode) repository worden opgeslagen?

Ja, maar het is dan moeilijker om de actualiteit van de tests te waarborgen, handmatige synchronisatie is vereist en er is een risico om iets te "vergeten" bij de release of bugfix.

Moeten tests onmiddellijk alle nieuwe functionaliteit dekken bij het creëren van een PR?

Ideaal gesproken – ja, in de praktijk dekken ze vaak MVP/belangrijke scenario's in de eerste PR, en complexe gevallen – afzonderlijke taken. Het belangrijkste is dat kritische functionaliteit onmiddellijk is gedekt.

Kan je alleen testwijzigingen terugrollen zonder de code terug te rollen?

Als tests en code samen in één tak staan – ja, revisies kunnen worden teruggedraaid. Maar het is beter om "terugrol" van tests zonder code te vermijden: dit verslechtert de kwaliteit van de controle.

Typische fouten en anti-patterns

Het opslaan van tests niet in git, maar op bestandssystemen
Het beheren van tests in een afzonderlijke repository zonder duidelijke verbinding met het project
Het toevoegen van tests vanuit externe bronnen (post factum), en niet gelijktijdig met de code

Voorbeeld uit het leven

Negatief geval

Project met een afzonderlijke repository voor geautomatiseerde tests. Na de release "vergeten" de programmeurs de tests bij te werken - tests vielen, er werden verouderde controles uitgevoerd, fouten werden in de productie ontdekt.

Voordelen:

Programmeurs konden onafhankelijk van QA werken

Nadelen:

Tijdverlies door synchronisatie, aanwezigheid van "verouderde" tests

Positief geval

Tests en de code van het project worden in dezelfde git-tak beheerd: bij elke nieuwe pull request worden de geautomatiseerde tests voor de toegevoegde code bijgewerkt. Alle wijzigingen ondergaan code review en automatische controles.