Automated Testing

Inleiding

Zonder Automated Testing (geautomatiseerd testen), kan Continuous Integration niet goed werken. Wanneer de code geïntegreerd wordt, maar er worden tijdens de build & test fase geen tests uitgevoerd, omdat deze bijvoorbeeld niet bestaan, dan kan de developer niet onmiddellijk te weten komen of de code werkt.

Hoe langer de tijd tussen het schrijven van de code en het uitvoeren van de test, hoe groter de kost (technical debt) zal zijn om de fouten in de code op te sporen en op te lossen. De developer moet namelijk een context switch uitvoeren van de feature die op dit moment ontwikkeld wordt, naar het oplossen van fouten in een feature die voor de developer al (lange tijd) afgewikkeld was. De code zal ook niet meer vers in het geheugen zitten, wat extra tijd met zich mee brengt om de code logica weer te verstaan en de fouten op te lossen.

Daarom is het belangrijk om zoveel mogelijk relevante tests uit te voeren zo dicht mogelijk bij het afwerken van een feature. Als deze tests automatisch uitgevoerd kunnen worden, dan kunnen bepaalde fouten al opgespoord worden nog voor dat de developer zijn feature afsluit.

Zowel developers als testers zullen automated tests moeten schrijven. Developers zullen op hun eigen tests moeten focussen (unit tests, regression tests, etc). De testers focussen zich op de automatisatie van hun acceptance tests.

Betrek Testers mee in het development proces

Het is belangrijk om testers mee te betrekken in het development proces. Ze dienen integraal deel uit te maken van het team. In Agile methodologieën zoals Scrum is dit een vereiste. De verouderde waterfall methodologie betrok de testers veel te laat in het proces, pas nadat het development afgelopen was, wat vaak leidde tot vertragingen en hoge technical debt.

Wanneer testers deel uitmaken van de planning meetings in een sprint (in Scrum methodologie), kunnen zij onmiddellijk al de te ontwikkelen tests bepalen op basis van de features (user stories) die ontwikkeld moeten worden. De testers dienen werk in te plannen en schattingen te maken voor onder andere:

  • Het aanmaken van test data
  • Het aanmaken van acceptance tests voor de user stories
  • Het design van test cases / acceptance test
  • Het uitvoeren van de tests
  • Design en/of verbeteringen van het test framework
  • Andere scripting taken
  • De juiste omgevingen op te zetten

Wanneer de sprint start dan gaan de testers aan de slag net zoals de developers. De testers kunnen focussen op het ontwikkelen van hun (geautomatiseerde) test cases.

In een volgende sprint kunnen de testers zich ook focussen op het ontwikkelen van automatische smoke tests en UI/regression tests dat niet ontwikkeld konden worden tijdens de sprint zelf. Het is ook belangrijk dat de testers mee deelnemen aan de review meeting en de retrospective. De testers kunnen bijvoorbeeld de interne of externe demo leiden.

Al deze acties die testers ondernemen zorgen er voor dat bugs zo snel mogelijk gevat worden zodat de kost om een bug op te lossen zo laag mogelijk blijft. Wanneer er veel later een fout opgelost moet worden dan is er niet alleen een stijging van de technical debt, maar er gaat ook kostbare tijd verloren van de developer, want deze moet een context switch uitvoeren om van huidige codebase naar de codebase van de bug over te gaan en omgekeerd. Door testers mee in het development team te brengen wordt van traditioneel testen afgestapt en wordt ook het testing team meer agile.

API tests

Applicaties hebben typisch meerdere lagen (layers). Tijdens de sprint is het al mogelijk voor de testers om volledige geautomatiseerde test cases te schrijven voor de (REST) API. Deze tests zullen eerst falen, want nieuwe API calls zullen nog niet geschreven zijn, maar naarmate het development vordert (de sprint), zullen de tests effectief de onderliggende business logic kunnen testen. Dit betekent dat van zodra een feature afgewerkt is, de tests onmiddelijk uitgevoerd kunnen worden. De feedback loop voor developer en tests is nu verkort tot uren, in plaats van dagen of weken in een waterfall methodologie.

Enkele producten die gebruikt kunnen worden voor API tests:

  • HTTP Client Library for java (Google)
  • Jersey Client & Jersey Test Framework (Oracle)
  • Spring RestTemplate (Pivotal)
  • Apache CXF Client

Het schrijven van tests

Testers hebben vaak geen (of maar een beperkte) developer achtergrond. De testers zullen een apart test framework moeten gebruiken om tests te ontwikkelen. Het is belangrijk om de implementatie van de test af te zonderen van de beschrijving van de test zelf. Dit maakt het mogelijk om testers een test scenario te laten schrijven zonder de onderliggende implementatie te hoeven verstaan. De implementatie zelf kan dan geschreven worden door een tester die meer development achtergrond heeft of een developer die tests mee helpt schrijven.

Er is software beschikbaar voor het opsplitsen van de beschrijving van de test en de implementatie zelf. Enkele bekende zijn:

  • Cucumber
  • JBehave

Behavior Driven Development

Software zoals Cucumber (een zeer populair pakket) laat toe om aan Behavior Driven Development (BDD) te doen. Het is mogelijk om de tests te schrijven voordat de software zelf ontwikkeld wordt. Dit kan dan dienen als specificatie voor de developers om de software te ontwikkelen. De developers zien dan onmiddellijk of ze een fout gemaakt hebben in de implementatie van feature. De Cucumber scenarios kunnen zo geschreven worden dat toekomstige teamleden begrijpen wat het systeem doet door alleen maar de test scenarios te lezen.

Het is ook mogelijk om UI tests uit te voeren met een combinatie van bijvoorbeeld Cucumber + Selenium, maar de echte kracht van een framework zoals cucumber zit in het uitdrukken van business rules in test scenarios. Een voorbeeld van zo een scenario in Gherkin (de beschrijvende taal in Cucumber):

Scenario: Some determinable business situation
  Given some precondition
    And some other precondition
  When some action by the actor
    And some other action
    And yet another action
  Then some testable outcome is achieved
    And something else we can check happens too

Dit scenario kan dan in bijvoorbeeld in Java geïmplementeerd worden. De implementatie is losgekoppeld van het beschrijven van het scenario zelf. Elke tester kan dit scenario ontwikkelen, maar waarschijnlijk zullen niet alle testers even comfortabel zijn om de implementatie te schrijven voor de test.

_images/contact-in4it.png