Naam: Thomas Droppert  

Studentennummer: 679586 

Klas: ITA-OOSE-A-s

Groep: SmallTalk

Procesbegeleider: Mark Giesen

Professional skills docent: Helen Visser en Sjir Schütt

Vak: OOSE project

Datum: 25-11-2022 

Inhoudsopgave

1. Inleiding:

Voor het OOSE-project ben ik ingedeeld in projectgroep Smalltalk. Onze groep heeft als opdracht gekregen van Regterschot Racing, om een API te bouwen, die zorgt voor een interactie tussen de database en de website. Het belangrijkste product voor Regterschot Racing is eigenlijk nog wel de documentatie. Met deze documentatie bouwt de volgende projectgroep verder op onze code. Als dit niet goed is, dan kunnen we stellen dat we het project dus ook niet hebben gehaald. Deze documentatie en de code moeten allemaal in het Engels geschreven worden, voor het geval dat de volgende projectgroep bestaat uit internationale studenten, die alleen Engels spreken

In dit document behandel ik mijn leerproces tijdens het project. Ik moet laten zien welke competenties ik ontwikkeld heb en welke kennis en vaardigheid ik heb toegepast tijdens dit project. Hierbij moeten ook de keuzes worden toegelicht over het proces.
In dit document zijn de volgende dingen te zien: mijn commentaar over belangrijke situaties zijn te zien, mijn leerdoelen komen aan bod, ik licht mijn competenties toe, ik geef een korte beschrijving van de rollen die ik gehad heb dit project, ik evalueerde gehanteerde projectmethode van het PvA en ik beoordeel de kwaliteit van het eindproduct. Aan het eind geef ik nog een conclusie over mijn leerdoelen en mijn competenties.

Het doel van dit verslag is om duidelijk over te brengen hoe het proces in het project verliep, vanaf mijn perspectief en wat ik van het project heb geleerd.
Als doel voor dit project zou ik graag een nuttige bijdrage willen leveren en zou ik graag een product willen opleveren waar Regterschot Racing op vooruit kan bouwen.
Hierbij wil ik ook leren hoe een werkdag er later uit zou zien en te leren om gestructureerd te werken in deze werkdag.
Vorig schooljaar heb ik het I-Project gedaan. Deze ervaring kan ik ook toepassen op het OOSE-project, aangezien beide projecten in scrum uitgeoefend wordt.

Een uitdaging voor mij is snel in een discussie schieten. Hierbij kan ik snel het perspectief van een ander vergeten of niet inzien. Dit kan ervoor zorgen dat een ander zich niet gewaardeerd voelt en het gevoel kan krijgen dat ze niks kunnen inbrengen in een groep. Daarom zou ik graag hierop willen letten in dit project. Als andere uitdaging heb ik het te snel beginnen aan taken, zonder goed te plannen/ontwerpen. Dit zorgt er vaak voor dat de taak opnieuw moet of veranderd moet worden. Daarom probeer ik ook ervoor te zorgen dat ik het plannen en ontwerpen goed onder de knie heb.

2. Deelproducten

In dit hoofdstuk ga ik uitleggen wat mijn kwaliteitsoordeel is over de alle deelproducten. Om een product goed te kunnen noemen, moet het voldoen aan de volgende eisen:

• Het product moet voldoen aan de kwaliteitseisen van het PvA (zie 6.1).
• Het product moet consistent zijn. Dit betekent bijvoorbeeld dat het SRS overeenkomt met de wensen van de opdrachtgever en het SDD overeenkomt met het SRS.
• Het product moet toegevoegde waarde hebben voor de opdrachtgever en school.

Ik zal hierbij aangeven waarom er iets wel, of niet goed is en dit terugkoppelen naar de bovenstaande punten.

2.1. Deelproduct PvA

Voordat de eerste sprint begon, heb ik meegewerkt aan het plan van aanpak. Het plan van aanpak moet een visie geven over hoe wij ons project gaan aanpakken. Het moet een document zijn waarop we terug kunnen kijken om te beoordelen of we in de goede richting gaan, of niet. Na mijn idee doet het plan van aanpak dit goed. Om een product te maken zullen we terug moeten kijken naar de kwaliteitseisen die zijn opgesteld in het PvA. We hebben het plan van aanpak gebaseerd op het "Toelichting plan van aanpak", document (Praktijkbureau AIM, 2022).

Voor het plan van aanpak heb ik vooral gewerkt aan hoofdstuk 5, 7 en 8. Hoofdstuk 8 gaat over de organisatie en communicatie in ons project. Hierin heb ik een aantal afspraken opgesteld en duidelijk gemaakt wanneer de gesprek overleggen plaatsvinden. 
In hoofdstuk 7 ontwikkelmethode, heb ik uitleg gegeven over de betekenis van de rollen en heb ik een deel van de scrum ceremonies uitgelegd. Hoofdstuk 5 was kort en heb ik aangepast na een review, waardoor het bijna zelf gemaakt was.
Zelf vind ik deze producten informatief en duidelijk. Het verteld de informatie meteen, zonder een lange draad erbij.

Het gehele plan van aanpak ziet er goed uit, omdat het ons een overzicht laat zien van hoe wij dit project moeten aanpakken en dat is precies waar het plan van aanpak voor is.

2.2. Deelproduct SRS

Het SRS was voor het tussentijdse inleverpunt niet goed. Dit komt aangezien er nog bijna niks aan gedaan was, behalve de introductie. Deze introductie vond ik zelf wel goed gemaakt, maar het product als geheel was niet goed. Dit was ook te blijken uit de tussentijdse beoordeling. Nadat dit beoordeeld was en verbeterd, vind ik het product er wel goed uitzien. De feedback van de docenten is verwerkt en we hebben het een lopend verhaal gemaakt voor onze opdrachtgever, zodat hij kan begrijpen hoe zijn visie eruit ziet als dit geprogrammeerd gaat worden. In de laatste sprint hebben we het SRS nog laten zien aan onze product begeleider. Hij had gezegd dat het er goed uitzag en dat het overeenkomt met zijn visie, waardoor dit deel van het project dus geslaagd is.

2.3. Deelproduct Een stuk code

Ik heb de code voor de login functie gemaakt. De code wordt voor meer dan 80% gecoverd en bevat geen code smells (Sonarqube, 2022).
In de eerste 2 sprints heb ik deze code gemaakt zonder eerst diagrammen te maken en het SRS bij te werken, waardoor de code vaak opnieuw moest. In sprint 3 was de code klaar, maar alleen nog niet de testen die hierbij hoorde. 
Uiteindelijk heb ik in sprint 4 de code afgemaakt met hierbij de test. Als ik eerder de sequence diagram van login had gemaakt, dan had dit veel tijd gescheeld. Het stuk code kwam uiteindelijk wel overeen met het SRS en SDD en was goedgekeurd door onze opdrachtgever. De login functie bevat nog wel veel logica in de service. Deze logica was wel nodig, maar hoorde niet thuis in de service, maar nog in een aparte klasse. Dit zorgde ervoor dat de code er een beetje slordig uitziet. Wel vind ik het fijn dat deze code return waardes heeft voor de methodes. Dit zorgt voor makkelijker testen en geeft wat duidelijkheid aan wat de methode precies doet. In de rest van ons programma wordt na mijn idee nog te veel void methodes gebruikt.

Deze code duurde lang om te maken, maar voldeed uiteindelijk aan de eisen van het plan van aanpak.

Mijn oordeel is daarom dat dit product voldoet aan de eisen van het PvA, maar beter gemaakt kan worden in verband met de loginservice.

2.4. Deelproduct Onderzoeksverslag

Voor het onderzoeksverslag ga ik kijken naar het data transfer onderzoek. Dit verslag is gemaakt om te weten te komen hoe we live data op de website kunnen zetten. Het onderzoek mist nog een discussie om de validiteit van het onderzoek aan te tonen (Scharwächter, 2022). In de tekst zit nog een niet verwerkte opmerking in van Wijnand. In de conclusie wordt de hoofdvraag beantwoord met behulp van de deelvragen. Elke deelvraag is gerelateerd aan de hoofdvraag en helpt bij het beantwoorden van deze vraag. De tekst maakt nog niet duidelijk uit welke bronnen de informatie gehaald wordt. Zo staat er in de tekst een stukje over NASCAR, waarbij het niet duidelijk is waar deze informatie vandaan kwam. Dit verslag koste naar mijn gevoel ook te veel tijd. Ik heb dit verslag gereviewed en er moest in de eerste paar versies nog veel verbeterd worden. Toen mijn opmerkingen verbeterd waren, had de tweede reviewer een aantal fouten gevonden, waardoor dit proces lang duurde. Het eindoordeel van het verslag is dus dat ik kan zien dat er over het onderwerp is nagedacht, alleen de structuur kan beter.

2.5. Deelproduct SDD

Er is veel tijd in het SDD gestopt. Dit kwam omdat onze code vaak uitgebreid of veranderd werd. We zijn laat begonnen met het SDD en begonnen te vaak met eerst coderen en dan het SDD aanpassen. Dit betekende vaak dat de code anders geschreven moest worden, omdat het verkeerd was. Het SDD voldoet wel aan de eisen opgesteld in het PvA en de huidige versie komt overeen met het SRS. Zo worden er bij de sequence diagrams de actors veranderd, gebasseerd op de rechten die de actoren hebben. Zo heeft login user en place graph een crewmember, omdat het plaatsen van een grafiek alleen maar mag gebeuren door een crewmember en niet een viewer. Dit is ook zo uitgelegd in het SRS. Het SDD is Engels, wat een eis is van ons plan van aanpak. Na mijn idee kan de uitleg voor de definities van acroniemen en afkortingen wat uitgebreider, aangezien er een aantal benamingen zijn die nog ingewikkeld kunnen zijn. Zo is bij de afbeelding voor Architectural Overview een CDN en DNS aanwezig. Deze afkortingen worden in de tekst daaronder uitgelegd, maar hadden dus ook bij 1.3 uitleg voor definities, acroniemen en afkortingen kunnen horen. Wel vind ik het fijn dat duplicerende gedeeltes in het class diagram zijn opgesplitst, zodat het class diagram zelf overzichtelijk blijft. Nadat we het SDD hebben laten zien aan Regterschot was de enige feedback die wij ontvangen hadden was dat de spelling beter kon. Dit hadden we daarna verbeterd en voldeed dus aan de wensen van Regterschot.

Kijkend naar de opgestelde criteria kan ik zeggen dat dit product aan de wensen voldoet.

2.6. Deelproduct Unittests

In ons project hebben wij 55 unittests gecreëerd die samen meer dan 80% code coverage vormen. Bij veel unittests gebruiken we assertNotNull om te testen of de functie werkt. Ik had eigenlijk verwacht dat we zouden testen op de data in plaats van de assertNotNull, omdat we dan weten of de logica zelf ook werkt en het niet een ander object teruggeeft. Op een aantal plekken wordt dit wel gedaan, maar ik had wel gehoopt dat dit overal zo getest zou zijn. We hadden uiteindelijk in de groep afgesproken dat we assertNotNull zouden testen, dus daarom is dit op veel plekken zo gedaan. Omdat we veel void methodes hadden, moest er veel getest worden met mockito.verify. De unittest bevatten resultaten voor zowel het goede pad, als het slechte pad. De unittests testen een aantal klassen niet, omdat deze buiten de applicatie zelf liggen. Zo wordt de connectie met de database niet getest, omdat dit niet getest kan worden. Het sluiten van een connectie wordt dus ook niet getest, omdat dat ook te maken heeft met de database.

2.7. Deelproduct Testplan & Testrapport

Ik heb het testrapport in elkaar gezet. Het testrapport bevat alle tests die wij in onze applicatie hebben. Terwijl ik bezig was met dit product, wilde ik eigenlijk graag een tussentijdse review hebben, aangezien ik niet helemaal wist of ik dit op de goede manier aan het aanpakken was. Dit werd helaas niet gedaan tot aan 3 dagen voor het inleveren, waarbij alleen Martin eroverheen had gekeken. Het document herhaalt veel tekst, waardoor het onnodig voelt. De testen zijn kort uitgelegd, maar bevatten wel de basiselementen om te kunnen omschrijven wat de test doet.  Het document mag ook meer introductie bevatten over wat het precies inhoudt. Wel vind ik het fijn dat er nog definitief wordt gezegd dat de test echt geslaagd is, zodat het in een overzicht is te zien. In dit project hebben wij ervoor gekozen om niet een testplan te maken. Hiervoor is gekozen, omdat de testen in het begin van ons project nog te onduidelijk waren en zodra we wisten hoe deze testen werden uitgevoerd, konden we alle testen al vrij snel maken. Het testplan was wel handig geweest als richtlijnen voor welke testen er plaats zouden vinden. 
Het document is in correct Engels geschreven. In het plan van aanpak staat als criteria voor het testrapport dat de database ook getest moet zijn, dit is alleen niet het geval. Hierdoor kan ik dus zeggen dat dit product niet voldoet aan de criteria die ik zelf had opgesteld en schiet het product dus te kort.

3. Eindproduct

In het PvA bij de definition of done en de op te leveren producten en kwaliteitseisen zijn de eisen te zien die we hebben opgesteld voordat het project begon. Deze eisen moeten zorgen voor een goed eindproduct. Voor Regterschot leveren wij de gebouwde applicatie en gerelateerde documenten in. Alle documenten die naar Regterschot Racing gaan zijn in het Engels geschreven. Het proces om deze producten te maken begon traag. In de eerste periodes konden we onze draai niet vinden. Dit zorgde voor veel vertraging en onduidelijkheid over wat de opdracht was. Tijdens de tussentijdse beoordeling was duidelijk te zien dat we het niet goed deden. Dit zagen we gelukkig allemaal in en begonnen met een plan om dit te verbeteren. We hebben het SRS en het SDD geüpdate, zodat het klopt met de wensen van Regterschot. Nadat dit verbeterd was, begonnen we met coderen. Door dit SRS en SDD goed te hebben, hadden we een duidelijke visie over hoe we het coderen moesten aanpakken en wat er in de code moet. Het SDD en SRS bevatten alle benodigde activiteiten om aan het product te komen.. De database was ook vaak veranderd, dit kwam omdat dat deel van het SDD nog niet goed genoeg was. Hierdoor verloren we ook weer tijd. Gelukkig hebben we dit wel opgelost, zodat de code goed werkt met de database. De database mist nog testen om te kijken of alles goed gaat met de database. Hierdoor voldoet de database niet aan de eis in het plan van aanpak. 

Zoals eerder gezegd komt ons project op minimaal 80% code coverage, waardoor we de applicatie reliable kunnen noemen. De front- en backend zien er beide gestuctureerd uit. De frontend kan visueel er nog beter uitzien, maar de stijl van de website maakte onze opdrachtgever niet uit. Daarom hebben we bewust de keuze gemaakt om ons te focussen op een werkende front- en backend. De data die wordt weergegeven van de grafieken komt nu nog te langzaam binnen. Ons originele plan was om dit twintig keer per seconde te doen, maar dit is nu twee keer per seconde geworden. Dit komt doordat de broker veel eist van de prestatie van het systeem. Ik vind het wel jammer dat dit niet sneller is en we hadden als team meer moeten helpen bij dit stukje code om dit opgelost te krijgen. Nou was er wel gezegd door onze opdrachtgever dat dit voor nu niet twintig keer per seconde weergegeven hoeft te worden op de website, maar dit kwam vooral omdat we anders de andere taken niet af zouden krijgen.

De backend code ziet er beter uit dan de frontend code. Dit komt vooral omdat we hier meer verstand van hadden. De backend is wel vaak aangepast, omdat het niet consistent was. Er waren packages met hoofdletters en zonder hoofdletters, functies kregen niet overal dezelfde naamstructuur als in andere klassen en er kwamen vaak klassen terug die verwijderd waren, omdat men in een oudere branch zat te werken. Dit zorgde wel voor wat vertraging, maar gelukkig niet veel vertraging. De backend is compleet en heeft overal op de login functie na, dezelfde structuur. De loginfunctie is hierbij de uitzondering, omdat deze klasse meer logica verreist.

Voor het opzetten van de code is door Martin nog een opzetdocument gemaakt. Het verteld hoe ons programma opgezet kan worden. Wel mis ik in dit document nog een uitleg over hoe IntelliJ gedownload moet worden. Dit is wel belangrijk voor iemand die coderen niet begrijpt. Naast dit punt vind ik de uitleg duidelijk genoeg. Ik heb dit zelf nog gereviewed en na dit reviewen had ik dus alleen nog het punt over IntelliJ kunnen vinden.

De API en de documentatie hierbij vind ik voldoende genoeg. De code is logisch opgebouwd en door unittests veilig gemaakt. De documentatie verteld in een lopend verhaal de werking van de code en de wensen van Regterschot.

4. Projectmethode

Het werken in een groepje op school via scrum werkt goed, als iedereen er is. In een groep kan er makkelijk een vraag worden gesteld en gelijk beantwoord, waardoor je sneller verder kan werken met waar je mee bezig was.
Door daily standups kan je horen wat andere teamgenoten gaan doen op een dag en hoe lang dat nog gaat duren Tijdens het project hebben we ook bijna elke ochtend een daily standup gehouden. De uitzonderingen hierop waren de begin van de sprints, waarbij er nog geen nieuwe taken waren. Door de daily standups kun je eventueel hulp aanbieden als ze te lang bezig zijn met een taak. Dit hoort allemaal bij de scrum-methode.
De bedoeling van scrum is dat je via iteratief werken (zie figuur 1), langzaam op een optimaal product komt. Voordat een sprint start, is het de bedoeling dat er een backlog wordt gemaakt waar alle mogelijke taken in voort komen. Een paar van deze 
taken worden vervolgens in de sprint planning uitgekozen en gaan mee de sprintbacklog in. Tijdens deze sprint werkt elk individueel teamlid aan een taak, totdat dit klaar is om gereviewed te worden. Als team hebben wij afgesproken om twee
leden te laten reviewen, voordat een taak naar done gaat. Na de sprint houden wij een sprint review met onze opdrachtgever, om hem te vertellen wat we gedaan hebben en wat hij nog zou willen zien. De eerste keer ging deze review nog
redelijk traag en wisten we nog niet goed wat we wilden vertellen. Hierdoor hebben we de afspraak gemaakt om de review 3 dagen van te voren al uit te werken, zodat Regterschot Racing snel en duidelijk kan zien wat er gedaan is.

Na de review zal er ook nog een retrospective plaatsvinden, waarin de groep elkaar feedback geeft en terugblikt naar de afgelopen sprint. Door IPV's in te vullen, kan er handig feedback naar voren komen op een anonieme en ook professionele
manier. Deze IPV's worden meestal via de GEIN methode ingevuld, zoals we dit hebben geleerd bij de professional skills lessen. Voor de eerste paar sprints hadden we de IPV's met een korte versie ingevuld die alleen wat zeggen over de projectbijdrage, zie bijlage IPV rapport sprint 1. We hadden besloten om een keer de wat langere versie te kiezen, zodat we meer gedetailleerd feedback konden geven. Dit bleek effectief te zijn, aangezien iedereen wist waar de problemen precies lagen. Er werd ook meer feedback gegeven, wat ook nuttig is, zie bijlage IPV rapport sprint 3.

Voor elke sprint hadden we een andere scrummaster gekozen. Deze scrummaster begeleidt het team door het proces heen en houdt overzicht over de taken. Aangezien we vijf sprints hebben, komt dus bijna iedereen aan bod. Alleen Martin was geen scrummaster, omdat hij de chef de mission was, dat betekent dat hij de product begeleider moet blijven informeren over de stand van zaken en anders twee rollen op zich zou moeten nemen..

Na mijn idee hebben we al de scrum regels de laatste paar sprints goed toegepast. De sprintplanning ging steeds beter, omdat we doorhadden hoe we dit goed konden doen. We gaven de taken specifieke namen, zodat het duidelijker was wat de taken inhielden. Het aantal uren per sprint werd ook beter ingeschat, dit is te zien door te kijken naar de burndown chart per sprint, zie bijlage burndown charts. Hoewel de eerste drie sprints nog niet goed verliepen, kwam dit vooral door de slechte toepassing van de sprintplanning. Tijdens sprint 4 bleek dat de broker meer tijd zou kosten dan origineel ingeschat, waardoor we de sprint net niet hadden gehaald. De rest van de taken tijdens sprint 4 waren wel goed ingeschat en daarom vind ik het toch een verbetering.

De eerste paar sprints hadden we scrum nog niet goed toegpast. We gingen te vroeg weg van school en werkte nog veel individueel. De daily standups gebeurde wel, maar waren ook niet goed uitgevoerd. Vergeleken met de laatste paar sprints, was dit dus nog een punt waar we aan moesten werken.

Figuur 1: Scrum procesverloop (HAN University of Applied Sciences [HAN], z.d.)

5. Rollen

5.1. Rol scrum master

In sprint 1 was ik scrum master, dit betekende dat ik overzicht moest houden op de taken en wat er gebeurd moet worden voor de eerste sprint.
Zelf merkte ik al snel dat ik als scrum master vaak de leiding kreeg over beslissingen buiten wat een scrum master moet doen. Als scrum master heb je namelijk de taak om te begeleiden, maar dat werd al snel leiden. De leiding nemen is niet iets wat ik graag wil doen, dus dit vond ik wel jammer. Hoewel ik dit niet leuk vind om te doen, is het toch belangrijk dat er een iemand is die het team begeleidt. Zelf had ik het gevoel dat ik als scrum master niet goed genoeg was. Bij het begeleiden van mensen, werd mijn advies bijna tot helemaal niet opgevolgd. Dit kwam meestal omdat andere teamleden een andere visie hebben over hoe ze bepaalde acties moeten uitvoeren. Dit leidde vaak tot een discussie, wat niet mijn bedoeling was. In het eerste IPV (zie bijlage IPV rapport sprint 1) is wel gezegd dat ik een goede scrum master was en kreeg ik twee plussen voor het bezig zijn met het maken van afspraken. Dit verbaasde mij wel een beetje, aangezien ik dus zelf vond dat ik niet goed genoeg was als scrum master. Naast het feit dat ik scrum master was, was ik vooral bezig met het reviewen van taken en het verbeteren van werk. Ik heb zelf in de eerste sprint nog niet veel uitgevoerd voor mijn eigen taken. Dit vond ik ook jammer, want zelf wilde ik ook bezig gaan met het schrijven van een verslag, maar iedereen was al bezig met een verslag en ik moest daardoor het SDD en SRS opzetten, waardoor ik alsnog wel nuttig bezig was, maar niet veel deed aan onderzoeken. Na het bekijken van mijn feedback in sprint 2, zag ik dat veel mensen hadden opgemerkt dat ik wat minder aan het woord was en wat minder de leiding nam. Dit gebeurde omdat ik niet meer scrummaster was. Daarom had ik besloten om toch wat meer “de leiding” te pakken. Hiermee bedoel ik niet zo zeer dat ik zei wat iedereen moest doen, maar meer iedereen aan wilde sturen wat ze kunnen doen en wat er nog gedaan moest worden. Ik had het gevoel dat dit nodig was, aangezien er veel tijd in de vorige sprint verloren ging aan afleidingen en het verkeerd handelen van taken.

5.2. Rol architect

In het afgelopen project startte ik vaak discussies. Deze discussies zorgden ervoor dat het voor mij helder was of alles nog met elkaar overeen kwam en of het werk efficiënt verricht werd, maar zorgde wel vaak voor irritaties bij anderen. Tijdens IPV gesprekken is deze rol vaak benoemd als de "architect". Tijdens dit project hield ik het SDD en SRS steeds meer in de gaten. Dit heeft ook te maken met mijn leerdoel van deze periode. De architect heeft als verantwoordelijkheid om een overkoepelende blik te hebben over de gehele architectuur. De rol werkt strategieën uit en benoemd de risico's die hierbij horen (GmbH, z.d.). Een paar skills die bij deze rol hoort is een sterke communicatie hebben en goed kunnen onderhandelen. Dit heb ik in het project vaak gedaan. Hoewel mijn communicatie beter kan, weet ik vaak de risico's te benoemen in iemands werk met onderbouwde argumenten. Om te zorgen dat ik minder onnodige discussie start, had ik mij voorgenomen om eerst bewijs te gaan verzamelen en te beredeneren waarom ik een bepaald standpunt had genomen. Daarna vertel ik wat ik gevonden heb en wacht ik de reactie van de groep af. Dit gebeurde bijvoorbeeld bij de hashfunctie voor een wacthwoord. Bram had een idee voor een manier van hashen. Deze manier bleek niet makkelijk uit te werken zijn. In plaats van gelijk in de discussie te schieten, besloot ik onderzoek te doen. De reactie nadat ik dit onderzoekje had laten zien was positief. Ze zagen de logica van mijn onderzoek in en waren het eens met mijn voorstel. Door dit zo aan te pakken heb ik veel onnodige discussietijd bespaart. Voor volgende discussies zal ik dit zeker weer proberen. Eerst de feiten zoeken, zorgt voor een goed discussie fundament. Als iemand anders toch iets beters bedacht heeft, moet ik mij daar ook bij toegeven. Het toegeven stuk is nog iets waar ik mij beter op kan ontwikkelen, daarom was dit ook een leerdoel van mij.

Teveel architecten in een groep creëert ook onrust in de groep. Vaak heeft de architect het luidste en grootste woord, waardoor een samenwerking met onderlinge architecten vaak niet goed verloopt. Ik moet hier goed opletten, zodat ik niet zorg voor onrust en chaos in de groep, maar dat de rust juist behouden wordt. 

6. Competenties

In dit hoofdstuk leg ik uit welke beslissingen ik heb genomen die hebben gezorgd voor een actieve bijdragen van dit project. Hierbij wordt gekeken naar welke overwegingen ik heb gemaakt en of deze beslissingen juist waren.

6.1. Competentie OOSE P-04: Het documenteren en ontwerpen van de software, met behulp van UML-diagrammen.

Voordat ik begon met dit project kon ik diagrammen die horen bij het project al redelijk goed maken. Voor de toetsen van OOPD had ik een voldoende gehaald. Hetgeen waar ik moeite mee had, was het toepassen van de theorie, aan de praktijk. Bij deze opdracht komen ook diagrammen aan te pas, waarbij ik moet nadenken hoe ik de opdracht ga vertalen in diagrammen. 

Voor de create tab functie, heb ik de system sequence diagram opgesteld. Voor login en create tab heb ik de normale sequence diagrams gemaakt (login sequence diagram, create tab diagram). Deze sequence diagrammen dienen als uitleg van de code. In het begin van het SDD heb ik de opzet voor het Design Class diagram gemaakt. In het design class diagram heb ik alle blauwe vakjes, ofwel dependencies, genoteerd en verbonden met de juiste klassen. Ik heb ook het hele SDD meerdere malen gereviewed, dit is allemaal te zien op JIRA. Door deze diagrammen te maken heb ik geleerd om meer gestructureerd te coderen. Ik heb mezelf voorgenomen om bij een aantal stukken code eerst de sequence diagrams te maken, zodat het coderen makkelijker zou verlopen. Hoewel de verandering niet heel significant was, vond ik het wel fijn dat ik in ieder geval een diagram had waarbij ik de richtlijnen voor mijn code kon vinden. Dit laat toch zien dat het wel belangrijk is om de sequence diagrams van tevoren te maken.

Door deze diagrammen kan ik dus meer gestructureerd coderen en weet ik wat beter hoe ik moet beginnen met een sequence diagram. Dit was vooral gelukt met de hulp van mijn groepsgenoten. Wijnand en Jasper hadden meer verstand over de diagrammen dan ik, dus ik vroeg hun vooral om hulp als ik het niet wist.  Voor opvolgende projecten kan ik vooral werken aan hoe ik de sequence diagram zo compleet mogelijk maak, zodat ik deze niet nog achteraf voor een deel aan moet passen.

6.2. Competentie OOSE P-05: De student implementeert een gedistribueerd systeem, evalueert het ontwerp en de realisatie en zorgt voor traceerbaarheid tussen dit en de functionele en niet functionele eisen.

Voor het ontwerpen van de code hebben we tijdens DEA geleerd hoe we een API kunnen bouwen door middel van Spotitube. Deze applicatie had ik nog niet helemaal af. Ik miste de unittests en de handling voor de excepties. De theorie achter de code snapte ik ook nog niet, zoals wat een service was of een controller. Tijdens het project heb ik gewerkt aan de backend code voor create tab en login. Hier en daar heb ik ook groepsleden geholpen met coderen wanneer ze ergens niet uitkwamen. Door het maken van de stukken code heb ik de definities geleerd van de applicatieonderdelen. Ik heb geleerd hoe ik excepties op kan vangen en terug kan gooien. Dit is hier te zien. De login functie hielp ook bij het leren van toepassen van compleet onbekende code. De wachtwoord hash die we gebruikt hadden was onbekend voor mij, maar begreep ik snel, omdat ik eerst met een andere hash tool had gewerkt voor het project, die niet toepasbaar was op de code. Door veel test te maken, begreep ik dit stuk ook eindelijk. In het begin van het project kon niemand goed testen. Dit betekende dat we een flinke achterstand in kennis hadden en tijd zouden moeten besteden aan het leren van het testen. Martin had een workshop gehouden, maar achteraf snapte ik het testen alsnog niet helemaal. Ik besloot goed te kijken naar de testcode van Martin en de theorie hierover, erbij te halen. Dit hielp enorm, want door de theorie en de praktijk te vergelijken, snapte ik wat Martin precies had gecodeerd. Hierdoor kon ik ook aan de slag met mijn eigen tests, die tot mijn initiële verbazing, begonnen te werken. Als ik tijdens DEA eerder was begonnen met unittests, terwijl de theorie hierbij werd uitgelegd, had ik de groep wel een hoop tijd bespaart. Voor de volgende keer wil ik dus graag proberen eerder mijn kennis op te bouwen, als ik merk dat niemand in een groep de kennis heeft om iets te doen. Met deze kennis kan ik het dan uitleggen aan de groep en het hopelijk voor hen ook duidelijk maken.

6.3. Competentie OOSE P-07: De student bewaakt de kwaliteit van de software door reviews en gestructureerd testen.

Zoals in de vorige competentie ook benoemd is, was ik aan het begin van het project nog niet zo goed in het schrijven van testen. Dit heb ik langzaam ontwikkeld over het project heen. Ik heb de tests geschreven voor de race functionaliteit. Ik heb Wijnand, Jasper en Sem geholpen met het oplossen van problemen die ze tegenkwamen tijdens het maken van de tests. Zo had Sem een probleem dat hij niet wist waarom er een nullpointerexception werd gegooid bij zijn test. Deze error had ik vaker gekregen en liep langzaam door mijn oplossingen heen. Ik dacht eerst dat het lag aan het feit dat de databaseconnection niet gemockt was. Dit bleek niet zo te zijn, aangezien in de setup methode dit wel werd gedaan. Vervolgens heb ik gekeken of hij de antwoorden van de resultset teruggaf. Hiermee bedoel ik de mockito.when functie in de code. Dit bleek nog niet gedaan te zijn, waardoor de code een nullpointer gaf. Toen ik hem had uitgelegd wat het probleem was, had hij het opgelost en kon hij weer verder met testen. Hiermee heb ik laten zien dat ik de code snap en het kan uitleggen aan projectgenoten. Het zoeken naar deze oplossingen in testen is voor mij wel fijn, aangezien ik dan weet of ik de code ook echt snap. Als er weer een probleem zou komen met een soortgelijk geval, weet ik dan ook dat dit waarschijnlijk een van de problemen is en kan ik iemand wat sneller helpen. 

Ik heb ook veel code van anderen gereviewd. Vaak waren dit useless imports die er nog instonden, of variabele die niet gebruikt werden. Als ik dit zag, dan zette ik opmerkingen bij de code waar het fout was en legde ik uit wat het probleem precies was. Dit gebeurde niet vaak via KOET, in de praktijk blijkt het toch vaak beter en efficiënter te zijn om te zeggen waar precies het probleem ligt in plaats van elke stap van KOET te doorlopen. Hier wijkt dus de theorie af van de praktijk.

7. Leerdoelen

Voor dit project bedenk ik een aantal leerdoelen waar ik mij aan wil houden. In dit hoofdstuk behandel ik de opgestelde leerdoelen en situatiebeschrijvingen. Als laatst laat ik mijn kernkwadranten zien voor dit project.

7.1.1.1. Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

Dit leerdoel heb ik gekozen, omdat in het vorig I-Project ik te weinig bezig was aan ontwerpen van bijvoorbeeld code.
Hierdoor moest mijn code vaak verbeterd worden, waardoor er te veel tijd verloren ging. Ik zou dit doel graag willen halen, zodat dit minder tijd verspilt voor mij 
en de groep.

Dit leerdoel kan ik bereiken door:

• Meer te werken aan het technisch ontwerp, zodat ik van tevoren een duidelijke visie heb op wat ik wil coderen. 
• De opdracht beter doorlezen en verdelen in sub-taken, zodat er een overzicht is van de taken. 
• Regelmatig anderen mijn code laten reviewen, zodat latere fouten op tijd gezien kunnen worden. 

7.1.1.2. Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.

Dit leerdoel heeft te maken met het realisme kernkwadrant. Dit leerdoel heb ik gekozen, aangezien ik vaak dingen alleen op mijn manier doe en niet op iemand anders manier. Dit maakt het werk meestal wel realistisch, maar niet ideaal.

Om dit leerdoel te halen heb ik een aantal stappen bedacht die ik kan doorlopen.

• Regelmatig vragen voor een 2e blik op mijn werk, wanneer ik denk klaar te zijn met mijn taak.
• Zorgen voor een goed overleg als meningen verschillen, hierbij vragen stellen zoals: "Waarom vind je dit?" of "Hoe sta jij hierin?".
• Als er iets is wat we allemaal moeten doen, dan kan ik vragen hoe een ander dit heeft aangepakt en deze aanpak kan ik dan eventueel opnemen in mijn werk, als dit goed beargumenteerd is.

7.2.  Conclusie leerdoelen

7.2.1.1. Leerdoel 1: Het efficiënter werken aan taken, door meer tijd te besteden aan het ontwerpen. 

Ik heb nog niet veel ontworpen in de eerste sprint, waardoor ik geen tijd heb besteed aan dit leerdoel. Er is ook niet veel code die gemaakt moest worden deze sprint.
De opdrachten van het JIRA bord waren ook nog niet helemaal goed verdeeld, waardoor ik veel werk kwijt was op een sub-taak, dat eigenlijk meerdere taken konden zijn.

Dit leerdoel was in de tweede en derde sprint nog steeds niet gelukt. Ik ben te vroeg begonnen aan het maken van de loginfunctie. Als ik dit wel had gedaan, had dit veel tijd gekost, waardoor ik echt wil opletten dat ik dit goed ga doen. Voor de volgende sprint/code functie, wil ik eerst het SRS maken. Dit ga ik proberen te onthouden door mijn tijd meer te besteden aan het reviewen van het SRS en SDD, zodat ik de prioriteit van deze documenten goed begrijp. Na het SRS ga ik de bijbehorende sequence diagrams maken en laat ik zorgen dat deze zo snel mogelijk gereviewd zijn. Voordat ik ga werken aan de functionaliteit, laat ik mijn sequence diagrams door twee teamleden reviewen, zodat ik zeker weet dat wat ik heb gemaakt, ook echt de bedoeling is van de opdracht.

In de vierde sprint heb ik er aan gedacht om eerst te beginnen aan het maken van alle diagrammen en de beschrijvingen hiervan (zie bijlage diagrams van tevoren maken). Mijn aanpak heeft dus gewerkt en mijn leerdoel is dus eindelijk bereikt.

7.2.1.2. Leerdoel 2: De mening van andere meer toenemen in mijn werk, zodat er een beter product kan ontstaan.

Ik heb dit leerdoel niet gehaald in de eerste paar sprints sprint. Ik viel nog te vaak in discussies. Het is niet gek dat ik dit toen nog niet heb gehaald, aangezien het de eerste paar sprints waren en vooruitgang in kleine stapjes gaat. In het IPV rapport van sprint 1 is te zien dat ik dit nog niet heb gehaald door te kijken naar de feedback. Voor de laatste paar sprints moet ik dus een scherper beeld hebben op dit leerdoel en moest ik ervoor zorgen dat ik dit doel niet uit het oog verlies.
Helaas kwam er een discussie (zie bijlage discussie login review) nadat mijn groepsleden mij feedback hadden gegeven. Dit wil ik graag verbeteren, door te zorgen dat ik bij frustraties een paar tellen wacht, voordat ik reageer op een antwoord. Ook zal ik proberen mijn frustratie wat meer weg te lachen. Hiermee bedoel ik dat ik mijn frustratie wat minder serieus moet nemen en moet kijken naar wat ik fout doe om deze frustratie te krijgen. Vooral wil ik hiermee zorgen dat ik niet meer boos wordt om deze voorgevallen.

Helaas is er in de laatste sprint geen IPV opgenomen. Ik heb namelijk het gevoel dat ik de laatste sprints hierop vooruit ben gegaan. Ik ben meer hulp gaan vragen over onderwerpen die ik niet snap. Als ik het gevoel had dat we iets verkeerd deden, dan vroeg ik eerst waarom ze vonden dat het zo moest, in plaats van dat ik gelijk probeer over te halen waarom ik vind dat het anders moet.

De laatste paar sprints ben ik ook niet boos of gefrustreerd geweest. Ik heb groepsgenoten geholpen wanneer ze hulp nodig hadden. Wanneer ik zag dat ze iets hadden gemaakt wat ik niet zo snel had gemaakt, begon ik eerst te vragen hoe ze erop kwamen, in plaats van mijn manier van maken uit te leggen. Zo leer ik namelijk wat de denkwijze van iemand anders is en kan ik daarmee de mening van die persoon meenemen in mijn werk.

7.3. Kernkwadranten

Een kernkwadrant laat in een oogopslag wat iemand zijn: valkuil, uitdaging, allergie en kernkwaliteit is. 

7.3.1. Kernkwadrant Bespraaktheid:

7.3.2. Kernkwadrant Realisme

8. Conclusie

We waren een iets te gezellige groep en konden vaak wat serieuzer werken. Dit zorgde voor een hele moeizame start in het begin. Ondanks dit slechte begin vind ik dat we een goed herstel hebben gemaakt.
Afgelopen sprints heb ik geleerd om het perspectief van anderen te begrijpen. Ik mag het dan misschien niet eens zijn, maar ik moet anderen toch de kans geven om hun perspectief te leveren en uit te leggen. Ik heb geleerd hoe het is om elke dag te moeten werken van 9:00 tot 18:00 in de week. Voor ons was dit in het project 9:15-18:15. Ik heb geleerd minder snel mijn eigen woord aan te nemen als waarheid, maar ook iemand anders de kans geven om zijn waarheid te spreken.

In het vorige project had ik het probleem dat ik mijn taken vaak opnieuw moest doen door slechte voorbereiding. Nu was het dit project wel een gelukt met de create tab functie. Ik hoop dat ik dit kan aanhouden voor de volgende projecten. 

In de laatste paar periodes, vooral na de tussentijdse beoordeling, hebben we echt een draai gemaakt en het project serieuzer aangepakt. Het is jammer dat dit niet meteen zo begon, maar wel fijn dat we dit tijdens het project gerealiseerd hadden en er wat aan deden om dit te verbeteren. Hierdoor hebben we uiteindelijk een nuttige bijdrage geleverd voor het Regterschot Racing team en voor school. De API voldoet aan de eisen van het PvA en de documentatie, al niet perfect, is toch na mijn gevoel op hoge standaard.

Het was wel fijn om in een groep samen te werken, omdat je zo kan leren hoe het later in het werkveld ook te werk gaat. Discussies en onderlinge gezelligheid zijn eenmaal niet te voorkomen, maar kunnen wel gereduceerd worden. 
Voor het volgende project moet ik proberen mijn leerdoel over discussies vast te houden en te kijken of ik hierin nog meer kan verbeteren. Graag zou ik willen zien dat ik echt compleet een discussie objectief kan beginnen, om zo een ander een echte kans te geven om zijn kant van het verhaal te geven.

9. Factsheet

De factsheet is te vinden op deze pagina of hieronder.

10. Bronnenlijst

10.1. Documenten die zorgen voor de structuur van het verslag

10.2. Documenten die inhoudelijk gebruikt worden

1. Praktijkbureau AIM. (2022). Toelichting plan van aanpak. In Onderwijs Online. HAN University of Applied Sciences. Geraadpleegd op 2 november 2022, van https://han.onderwijsonline.nl/elearning/lesson/Kqe86W3D
2. HAN University of Applied Sciences [HAN]. (z.d.). Les 5 wk_5_OOSE_Methode en planning_2022-2023_stud [Presentatieslides; Website]. OnderwijsOnline. https://han.onderwijsonline.nl/elearning/lesson/pNWX2Z9y
3. Sonarqube. (2022, 5 december). SonarQube. Geraadpleegd op 13 januari 2023, van https://sonarqube.aimsites.nl/dashboard?id=nl.han.oose.smalltalk
4. GmbH, L. (z.d.). IT Architects: Types, Roles, and Skill Sets | LeanIX. LeanIX. Geraadpleegd op 13 januari 2023, van https://www.leanix.net/en/wiki/ea/it-architects?utm_term=it+architect
5. Scharwächter, V. (2022, 20 december). Discussie schrijven voor je scriptie | Inclusief voorbeeld. Scribbr. https://www.scribbr.nl/scriptie-structuur/discussie-scriptie/

11. Bijlagen

11.1. IPV rapport sprint 1

11.2. IPV rapport sprint 2

11.3. IPV rapport sprint 3

11.4. Burndown charts

11.5. Situatiebeschrijvingen

11.5.1. Situatie: Discussie login review

In sprint 2 was er een discussie begonnen over hoe de loginfunctie veranderd moest worden. Dit gebeurde na het reviewen van mijn taak. Wijnand en Bram waren mijn stukje code aan het reviewen en zagen dat er een aantal aanpassingen gedaan konden worden. In dit geval ontving ik dus feedback en gaven Bram en Wijnand hun feedback. Ik had verwacht dat ik mijn code nog wel wat had moeten aanpassen, want ik zal best een paar dingen over het hoofd hebben gezien. Ik kreeg mijn feedback terug en besloot de aanpassingen die zij hadden toegelicht te implementeren, zodat ik klaar zou zijn met het maken van de login. Mijn frustratie over het maken van deze loginfunctie lag hoog, want ik zat al boven de geschatte tijd in en wilde graag bezig zijn met andere competenties. Na het verbeteren had ik aangegeven dat mijn stukje code verbeterd was en weer klaar was om gereviewed te worden. Dit keer verliep het alleen anders. Veel van wat ik net moest veranderen aan mijn code, moest weer op een andere manier gedaan worden dan bij de vorige review was aangegeven. Dit ging vooral over het geven van tokens en het hashen van een wachtwoord. Ik was hier boos om geworden, omdat ik weer tijd had besteed aan een stukje code, om vervolgens te horen dat het weer anders moest. Aangezien ik deze sprint al vaker problemen had gehad met de loginfunctie, besloot ik dat ik wilde stoppen met het maken van deze code, aangezien ik er niet meer onderuit kwam. Dit deed ik alleen op een best wel boze manier en dit had ik anders kunnen aanpakken. Als ik mijn frustratie had uitgelegd en gevraag om een oplossing, dan was dat een betere optie geweest, dan het werk verschuiven naar iemand anders. Ik dacht dat door mijn werk naar iemand anders te verschuiven, er een teamlid zou zijn die er meer van wist en het dus sneller af zou maken. De groep had aangegeven in het IPV dat dit wel anders gehandeld had kunnen worden, waarbij ik het ook mee-eens ben. Ik had niet boos moeten worden en naar oplossingen moeten zoeken.

11.5.2. Situatie: Diagrams van tevoren maken

Ik had als taak gekozen om de tab aanmaak functie te maken. De vorige keren dat ik een functie ging maken, begon ik met de code en ging ik daarna pas de diagrammen maken. Dit resulteerde in een slordige en onduidelijke login functie, die ik meerdere malen moest verbeteren. Ik begon een branch aan te maken en wilde net gaan coderen, totdat het besef in mij kwam dat ik niet echt goed wist waar ik moest beginnen. Ik besloot mijn code af te sluiten en te beginnen aan het maken van de diagrammen. Door deze diagrammen te maken, kon ik richtlijnen creëren die mij zouden helpen bij het maken van de code. Ik had eerst het SRS gedeelte gemaakt en gevraagd aan Bram en Jasper gevraagd of wat ik had gemaakt, goed was. Na een korte reviewen, was het enige deel feedback dat er nog een paar spellingsfouten inzaten. Deze had ik eruit gehaald en ben toen begonnen aan het sequence diagram. Dit bleek wat moeilijker te zijn dan dat ik had gedacht, omdat er te moeilijk over nadacht. Ik had Wijnand om hulp gevraagd en die gaf wat uitleg over zijn sequence diagram, waardoor ik wist hoe ik mijn sequence diagram kon maken. Nadat ik deze diagrammen afhad met beschrijving erbij, liet ik deze weer reviewen door twee groepsleden. Dit werd nog een keer goedgekeurd en ik ben toen begonnen met coderen. Ondanks de sequence diagram, heb ik nog er nog wel vanaf geweken. De aanpassingen die ik had gemaakt aan de code, heb ik vervolgens ook weer aangepast aan de sequence diagram. De sequence diagram zorgde er wel voor dat het coderen sneller ging, omdat ik wist waar ik naartoe wilde werken. Door een structuur in het codingsproces te krijgen, kan er dus duidelijkheid komen in wat en hoe je gaat coderen. Voor de volgende keer zou ik wel graag willen dat mijn sequence diagram wat beter is en dat het niet aangepast hoeft te worden.

11.6. Voorbeelen van unittests

11.6.1. GraphDAO test

package nl.aim.regterschotracing.datasource.dao;

import nl.aim.regterschotracing.datasource.databaseutil.DatabaseConnection;
import nl.aim.regterschotracing.domain.exceptions.DatabaseException;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;

import java.sql.ResultSet;
import java.sql.SQLException;

import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.ArgumentMatchers.anyString;
import static org.mockito.Mockito.*;

class GraphDAOTest {

  Integer tabID = 1;
  Integer graphID = 1;
  String graphType = "LineChart";

  @InjectMocks
  GraphDAO sut;
  @Mock
  DatabaseConnection mockDatabaseConnection;
  ResultSet mockedResultSet;

  @BeforeEach
  void setup() {
    sut = new GraphDAO();
    mockDatabaseConnection = mock(DatabaseConnection.class);
    mockedResultSet = mock(ResultSet.class);
    sut.setDatabaseConnection(mockDatabaseConnection);
  }

  @Test
  void getGraphs() throws SQLException {
    when(mockDatabaseConnection.selectQuery(anyString(), any())).thenReturn(mockedResultSet);
    when(mockedResultSet.next()).thenReturn(true).thenReturn(false);

    assertNotNull(sut.getGraphs(tabID));

    verify(mockDatabaseConnection).selectQuery(anyString(), any());
  }

  @Test
  void getUserTabsSqlException() throws SQLException {
    when(mockDatabaseConnection.selectQuery(anyString(), any())).thenThrow(SQLException.class);
    assertThrows(DatabaseException.class, () -> {
      sut.getGraphs(tabID);
    });
    verify(mockDatabaseConnection).selectQuery(anyString(), any());
  }

  @Test
  void addGraphsTestSqlException() throws SQLException {
    when(mockDatabaseConnection.selectQuery(anyString(), any())).thenReturn(mockedResultSet);
    doThrow(SQLException.class).when(mockDatabaseConnection).executeUpdate(anyString(), any());
    when(mockedResultSet.next()).thenReturn(true).thenReturn(false);
    assertThrows(DatabaseException.class, () -> {
      sut.addGraph(1, 1, "linechart");
    });
    verify(mockDatabaseConnection).executeUpdate(anyString(), any());
  }

  @Test
  void deleteGraphsTest() throws DatabaseException, SQLException {
    doThrow(new SQLException()).when(mockDatabaseConnection).executeUpdate(anyString(), any());
    assertThrows(DatabaseException.class, () -> {
      sut.deleteGraph(1, 1);
    });
    verify(mockDatabaseConnection).executeUpdate(anyString(), any());
  }

  @Test
  void addGraph() throws SQLException {
    when(mockDatabaseConnection.selectQuery(anyString(), any())).thenReturn(mockedResultSet);
    when(mockedResultSet.next()).thenReturn(true).thenReturn(false);

    sut = mock(GraphDAO.class);

    sut.addGraph(tabID, graphID, graphType);
    verify(sut).addGraph(tabID, graphID, graphType);
  }

  @Test
  void deleteGraph() throws SQLException {
    when(mockDatabaseConnection.selectQuery(anyString(), any())).thenReturn(mockedResultSet);
    when(mockedResultSet.next()).thenReturn(true).thenReturn(false);

    sut = mock(GraphDAO.class);

    sut.deleteGraph(tabID, graphID);
    verify(sut).deleteGraph(tabID, graphID);
  }
}

11.6.2. GraphService test

package nl.aim.regterschotracing.domain.services;

import nl.aim.regterschotracing.datasource.dao.GraphDAO;
import nl.aim.regterschotracing.domain.exceptions.DatabaseException;
import nl.aim.regterschotracing.presentation.dto.GraphsDTO;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.Mockito;


import java.util.ArrayList;
import java.util.List;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.mockito.ArgumentMatchers.anyString;
import static org.mockito.Mockito.*;

public class GraphServiceTest {
    @Mock
    public GraphService sut;
    @InjectMocks
    public GraphDAO graphDAO;
    @Mock
    public GraphsDTO graphDTO;

    @BeforeEach
    public void setup() {
        sut = new GraphService();
        graphDAO = Mockito.mock(GraphDAO.class);
        sut.setGraphDAO(graphDAO);
        graphDTO = new GraphsDTO();
        graphDTO.setName("test");
        graphDTO.setTabId(1);
        graphDTO.setId(1);
    }

    @Test
    void getAllGraphsTest() {
        //Arrange
        List<GraphsDTO> mockedData = new ArrayList<>();
        mockedData.add(graphDTO);

        //Act
        Mockito.when(graphDAO.getGraphs(1)).thenReturn(mockedData);


        //Assert
        assertEquals(sut.getAll(1).get(0), graphDTO);

    }

    @Test
    void addGraph() throws DatabaseException {
        doThrow(DatabaseException.class).when(graphDAO).addGraph(anyInt(), anyInt(), anyString());
        assertThrows(DatabaseException.class, () -> {
            sut.addGraph(1, 1, "linechart");
        });
        verify(graphDAO).addGraph(1, 1, "linechart");
    }

    @Test
    void deleteGraphs() throws DatabaseException {
        doThrow(DatabaseException.class).when(graphDAO).deleteGraph(anyInt(), anyInt());
        assertThrows(DatabaseException.class, () -> {
            sut.deleteGraph(1, 1);
        });
        verify(graphDAO).deleteGraph(1, 1);
    }

}

11.6.3. GraphResource test

package nl.aim.regterschotracing.presentation.resources;

import nl.aim.regterschotracing.domain.services.GraphService;
import nl.aim.regterschotracing.presentation.dto.GraphsDTO;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;

import java.util.ArrayList;
import java.util.List;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.mock;

public class GraphResourceTest {
    @Mock
    private GraphResource sut;
    @InjectMocks
    GraphService graphService;

    String token;
    List<GraphsDTO> graphsDTOList;
    final int http_statuscode_ok = 200;

    @BeforeEach
    public void setup() {
        sut = new GraphResource();
        graphService = mock(GraphService.class);
        token = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJyb2xlIjo0MiwidXNlcm5hbWUiOiJFcmlrIn0.FA26z63uwWWOfOM8EHfdBiYw6DzcfAF6EJ4YzZiQ-q0";
        sut.setGraphService(graphService);
        GraphsDTO graphsDTO1 = new GraphsDTO();
        GraphsDTO graphsDTO2 = new GraphsDTO();
        graphsDTO1.setName("test");
        graphsDTO1.setId(1);
        graphsDTO1.setTabId(1);
        graphsDTO2.setName("test");
        graphsDTO2.setId(2);
        graphsDTO2.setTabId(1);
        graphsDTOList = new ArrayList<>();
        graphsDTOList.add(graphsDTO1);
        graphsDTOList.add(graphsDTO2);
    }
    @Test
    void addGraphTest() {

        int testValue = sut.addGraph(1,1,"line").getStatus();
        assertEquals(http_statuscode_ok, testValue);
    }
    @Test
    void deleteGraphTest(){
        int testValue = sut.deleteGraph(1,1).getStatus();
        assertEquals(http_statuscode_ok, testValue);
    }

}