Component testen worden steeds vaker geschreven voor microservices. Meer teams komen erachter dat component testen het development proces makkelijker maakt en versnelt. Maar hoe schrijf je nou goede component testen? En hoe zet je deze op in de complexe omgevingen waar we mee te maken hebben?
Voor deze module hebben we een microservice geschreven die gebruik maakt van de meest complexe technologieën van deze tijd. Je zult stap voor stap libraries gaan gebruiken en oplossingen implementeren om met deze technologieën om te gaan. De belangrijkste technologieën die we behandelen zijn:
- databases
- rest api endpoints
- event based messaging
- externe dependencies
Daarnaast zullen we cucumber gebruiken voor de testen.
Voor deze cursus wordt er van je verwacht dat je basiskennis hebt van java, json en yaml.
Over de instructeur
Fin Kingma
Ik ben Fin Kingma. Een Agile Tester met een zware fascinatie voor de soft kant van IT. Tools en technieken zijn geweldig en kunnen je onwijs goed helpen om betrouwbaar kwaliteit op te leveren, maar ik ben van mening dat echte kwaliteit valt en staat met de mensen die aan het product werken. En ik geloof daarmee dat het meest effectieve team op aarde in staat is om betrouwbare software op te leveren zonder ook maar iets te automatiseren. Maar kwaliteit kost gewoon tijd en energie. En het heeft geen zin om je processen efficienter te maken, terwijl je teams nog nauwelijks weten waar ze bezig zijn. Laten we er daarom eerst voor zorgen dat iedereen weet hoe ze echt ‘waarde’ kunnen toevoegen in het werk dat zij doen, dan kunnen we ons daarna wel druk maken over de efficientie daarvan.
Bekijk meer cursussen van Fin Kingma →
Cursusoverzicht
| Welkom | |||
| Introductie | 00:02:00 | ||
| Benodigdheden van de cursus | 00:10:00 | ||
| Structuur van de cursus | 00:00:00 | ||
| Component testing basics | |||
| 1.1 Wat is een component test | 00:03:00 | ||
| 1.2 Waarom zijn component testen zo waardevol? | 00:03:00 | ||
| Uitleg van de microservice die we gaan gebruiken | |||
| 1.3 Clone de repository en open deze in intellij | 00:05:00 | ||
| 1.4 Event based messaging architectuur | 00:05:00 | ||
| 1.5 Functionaliteit | 00:05:00 | ||
| 1.6 Architectuur | 00:05:00 | ||
| Maak een Cucumber Runner die de applicatie kan opstarten | |||
| 2.1 Component test configuratie | 00:00:00 | ||
| 2.2 Toevoegen van dependencies | 00:05:00 | ||
| 2.3 Voeg een CucumberRunnerTest toe | 00:05:00 | ||
| 2.4 Voeg een ComponentTestConfiguration toe | 00:05:00 | ||
| 2.5 Voeg een leeg scenario toe | 00:05:00 | ||
| 2.6 Resultaat van de test | 00:05:00 | ||
| Vervang de database met een H2 in memory database | |||
| 3.1 Afhankelijkheden | 00:00:00 | ||
| 3.2 Toevoegen van dependencies | 00:05:00 | ||
| 3.3 Voeg cucumber application properties toe | 00:05:00 | ||
| 3.4 Gebruik de cucumber application properties | 00:05:00 | ||
| 3.5 Resultaat van de test | 00:05:00 | ||
| Vervang de event based messaging | |||
| 3.6 Toevoegen van dependencies | 00:05:00 | ||
| 3.7 Resultaat van de test | 00:05:00 | ||
| Schrijf je eerste feature file voor de rest api | |||
| 4.1 Project feature | 00:00:00 | ||
| 4.2 Toevoegen van dependencies | 00:05:00 | ||
| 4.3 Schrijf en implementeer je eerste scenario | 00:00:00 | ||
| 4.4 Uitwerking van het eerste scenario om een project toe te voegen | 00:05:00 | ||
| 4.5 Good practice #1: Schrijf generieke step definitions die herbruikbaar zijn voor andere scenarios | 00:05:00 | ||
| 4.6 Uitwerking van de api step definitions | 00:10:00 | ||
| 4.7 Schrijf nu het tweede scenario om te controleren dat project names uniek moeten zijn | 00:00:00 | ||
| 4.8 Uitwerking van scenario om te controleren dat project names uniek moeten zijn | 00:05:00 | ||
| 4.9 Good practice #2: gebruik de dao om testdata te genereren | 00:05:00 | ||
| 4.10 Voeg een derde scenario toe om een project te verwijderen | 00:00:00 | ||
| 4.11 Uitwerking van een derde scenario toe om een project te verwijderen | 00:05:00 | ||
| Schrijf je tweede feature file voor de event based testdata logica | |||
| 5.1 Testdata feature | 00:00:00 | ||
| 5.2 Good practice #3: focus je testen op losse requirements | 00:05:00 | ||
| 5.3 Schrijf en implementeer een scenario waarin testdata als event binnenkomt | 00:00:00 | ||
| 5.4 Uitwerking van een scenario waarin testdata als event binnenkomt | 00:05:00 | ||
| 5.5 Uitwerking van de step definitions om events in te sturen | 00:05:00 | ||
| 5.6 Schrijf de step definition om berichten uit te lezen van de uitgaande queue | 00:05:00 | ||
| Schrijf je derde feature file om gebruik te maken van de informatie uit de externe dependency | |||
| 6.1 Rating feature | 00:00:00 | ||
| 6.2 Toevoegen van dependencies | 00:05:00 | ||
| 6.3 Good practice #4: mock je externe dependencies weg zodat je geen afhankelijkheden hebt buiten je code | 00:05:00 | ||
| 6.4 Start wiremock op als onderdeel van de configuratie | 00:05:00 | ||
| 6.5 Voeg een wiremock interactie toe om de externe dependency te mocken | 00:05:00 | ||
| 6.6 Voeg een rating scenario toe | 00:00:00 | ||
| 6.7 Uitwerking van een rating scenario | 00:05:00 | ||
| 6.8 Good practice #5: hou je test opzet zo klein mogelijk | 00:02:00 | ||
| Afsluiting | |||
| Conclusie | 00:01:00 | ||
| Het Praegus Supportkanaal | 00:02:00 | ||
Reviews
Er zijn nog geen reviews geschreven voor deze cursus. Wees de eerste die er een schrijft!
