Automatisch testen van project, beste aanpak?

[alienfruit]

Ik vraag mij al enige tijd af wat de beste aanpak is voor het testen van een project en dan met name de backend. Mijn huidige aanpak tot nu toe is gelaagd middels:

1. End-to-end tests: Hier voer ik reeks een tests om te verifiëren om de beste functionaliteit werkt (e.g. user stories)
2. Unit tests: Tests van de functionaliteit per service / onderdeel
3. API tests: hierbij test ik handmatig de input-output van API endpoints middels een Postman collection

Het liefst zou ik de meeste van deze handmatige stappen 1 en 2 willen automatiseren. Voor de end-to-end tests zou ik Cypress kunnen gebruiken om zodoende de customer facing functionaliteit te testen. Ik zie hier eigenlijk twee verschillende varianten één voor de pull requests waar alle API endpoints worden gemocked om snel te kunnen testen dat er geen nieuwe fouten in de web interface worden geïntroduceerd en bij een merge to master misschien testen in een nieuwe testomgeving waar alles van master wordt gedeployed en vervolgens alle testen worden gedraaid.

Een mooi doel zal zijn dat ik een set van de end-to-end tests zou kunnen draaien in de productieomgeving na een nieuwe versie is gedeployed en nadat deze tests zijn afgerond een database wijzigingen weer terugdraaien. Maar dat lijkt mij niet eenvoudig om te doen.

Mijn vraag is eigenlijk wat is een goede manier om deze soort tests te automatiseren? Hoe pakken jullie het testen aan? Vooral als je geen echte QA persoon in je team hebt?

[Ed Vertijsment]

Ten eerste wil je je test en productie omgevingen gescheiden houden, hier is OTAP voor, de exacte workflow wil nog wel is verschillen maar komt meestal neer op iets als:

• Ontwikkeling: jouw lokale machine waarop je werkt, lokaal tests draaien.
• Test: test/buildserver (bijvoorbeeld: Jenkins/Travis) waarop je automatisch alle tests draait en eventueel doorzet (handmatig of automatisch) naar een testomgeving waarop je rond kan klikken en de database vrij kan "vervuilen".
• Acceptatie: vergelijkbaar met een testomgeving maar dichterbij de werkelijkheid, voornamelijk zodat de klant kan testen.
• Productie: Afblijven (maar wel backups maken, en check of die compleet zijn.)

Je wilt dus vooraal op je build server aan de gang. Zeker niet op productie.

Nadat je verschillende omgevingen hebt, wil je goed hebben wat je wil testen. De beste test is een klant die klikt een feedback geeft. Het is echter lastig om continu de klant te laten klikken. Een intergratie of end-to-end test is dan vaak het meest representatief. Zeker bij web applicaties omdat je dan echt gaat dealen met de complexiteit van een browser omgeving in plaats van simulaties daarvan. Je gaf aan dit te gebruiker voor user stories, ik ga er vanuit dat, dat dus wel snor zit.

Een integratietest is vaak wel grof geschut als je alle mogelijke code paden van een functie wil testen. Dus daarvoor is het vaak wenselijk een unit test te maken, daarmee kan je zonder veel overhead gericht een stuk code testen. Houd er wel rekening mee dat dit niet altijd even boeiend is. In grote lijnen vind ik het belangrijker dat een functionaliteit werkt dan of de tests voor een klein stukje code slaagt. Het is echter wel heel handig om bijvoorbeeld validatie functies op deze manier te testen.

Zowel intergratie als unit tests draaien wij gewoon vanuit de testrunner van het project. De API tests zijn ook gewoon geschreven als unit tests. Dit zorg ervoor dat alles met 1 script afgetrapt kan worden. De exitcode van het script geeft aan of een build succesvol is verlopen, vervolgens keurt Jenkins een pull request af of goed.

Je wilt hiervoor:

• Voor jouw programmeertaal/framework een test toolchain.
• Eventueel een koppeling met een integratietest tool (zoals Selenium).
• Een build server die tests kan draaien.
• Een hook naar je github/bitbucket/whatever die pull request laat checken.

^ Overigens zijn er tal van andere setups mogelijk. En we zijn nog niet eens in continues deployment gedoken maar misschien heb je er wat aan.

[alienfruit]

Hmm, dus je schrijft de API tests ook uit in bijv. Jest (als je TypeScript gebruikt) of NUnit? Een of andere manier had ik het idee dat er nieuwe oplossingen hiervoor waren. Andere projecten heb ik hiervoor supertest met Jest gebruikt.

Ik snap het OTAP idee en heb hier ook eerder meegewerkt alleen probeer ook de Excel spreadsheet om te zetten naar een integratietoop zoals TestCafe of Cypress. Meestal zou ik dan de HTTP responses van de APIs mocken zodat de tests lekker snel zijn. Dit werkt wel. Alleen hier loop ik wel tegen wat dingen wat hoe je test OAuth oplossingen? Bijv. hoe wil je Google Login of Github login testen op deze manier? Als je de EULA leest van Google mag je eigenlijk geen bots gebruiken en neem aan dat Cypress/Selenium een bot?

Het probleem waar ik vaak tegen aan liep is dat de data toch iets anders is of werkt dan in de andere omgevingen bijv. door externe onderliggende systemen. Daarom had ik het idee of misschien na een release ook een setje tests te draaien in Productie en vervolgens na de test alleen datastore wijzigen terug te draaien. Als je event sourcing zou gebruiken dan kan je ook iets schrijven waar je events kan terugdraaien toch? Moet toegeven dat ik dat zelf nog nooit heb geprobeerd.

[OverloadOfRed]

alienfruit schreef op dinsdag 26 mei 2020 @ 18:20:
...
Alleen hier loop ik wel tegen wat dingen wat hoe je test OAuth oplossingen? Bijv. hoe wil je Google Login of Github login testen op deze manier? Als je de EULA leest van Google mag je eigenlijk geen bots gebruiken en neem aan dat Cypress/Selenium een bot?
...

Je overige vragen heb ik als noob weinig inzichten op, maar meestal test je wat je kan testen en beschouw je externe systemen of systemen van derde partijen als 'black box' die door de makers van dat systeem zelf getest wordt. Je kan best Google Login of Github gaan testen, maar daar schiet je weinig mee op.

[Matis]

Door de juiste abstractie kun je die interfaces prima mocken.

Wij werken met Symfony en PhpUnit en hebben op alle drie de niveaus die jij noemt testen liggen, zonder dat er ook maar 1 externe tool en/of browser voor nodig is.

We hebben speciale kernels voor onze testen met mock- of memory implementaties van diverse externe interfaces.

[edeboeck]

OverloadOfRed schreef op dinsdag 26 mei 2020 @ 19:29:
[...]


Je overige vragen heb ik als noob weinig inzichten op, maar meestal test je wat je kan testen en beschouw je externe systemen of systemen van derde partijen als 'black box' die door de makers van dat systeem zelf getest wordt. Je kan best Google Login of Github gaan testen, maar daar schiet je weinig mee op.

Ik weet niet of de TS het zo bedoelt, maar wat als je functionaliteit wilt testen die achter een OAuth login zit (b.v. inschrijving waarvoor user eerst aangemeld moet zijn)?

[BCC]

Dan mock je de HTTP requests. Met VCR of Webmock of iets dergelijks.

[OverloadOfRed]

edeboeck schreef op dinsdag 26 mei 2020 @ 20:47:
[...]
Ik weet niet of de TS het zo bedoelt, maar wat als je functionaliteit wilt testen die achter een OAuth login zit (b.v. inschrijving waarvoor user eerst aangemeld moet zijn)?

Antwoord daarop ligt vooral aan het precieze probleem natuurlijk. Als het gaat om requests met een token wat je uit je oauth login krijgt ligt het voor de hand dat je dat gaat mocken. Jest heeft ook ondersteuning om specifieke modules te mocken, waarbij je bijvoorbeeld je authorizatie/authenticatie functie of check daarop kan mocken.
https://jestjs.io/docs/en/manual-mocks

[alienfruit]

Ja, ik snap dat je requests kan mocken en dat je externe partijen niet wilt testen en vanuit moet gaan dat deze wordt getest door de makers. Het liefst zou ik zo weinig mogelijk handmatige tests hebben en zoveel mogelijk automatiseren.

Ik twijfel alleen wat de beste aanpak is, persoonlijk geeft mij het mocken van de requests in bijv. Cypress/Selenium niet echt vertrouwen dat een Google OAuth flow blijft werken bijv. om te voorkomen dat instellingen wijzigen bijv. callback of redirect urls etc. Voor zoiets zou je toch eigenlijk door de flow moeten lopen?

Een andere voorbeeld zou zijn een dienst zoals Mailgun voor het versturen van mails, in je unit tests kan je makkelijk `jest.mock` gebruiken en dan controleren dat de `send`-functie (via `jest.fn()`) wordt aangeroepen in de test. Alleen als onderdeel van een integratietest wil je toch ook testen of de mail wel aan komt bijv. een signup? Ik vraag mij dus af hoe jullie zoiets aanpakken, heb je gewoon volste vertrouwen dat alles werkt? Om er vervolgens in de prepod of prod achter te komen dat het niet werkt?

Het einddoel is eigenlijk om zo min mogelijk handmatige stappen te hebben

[ Voor 3% gewijzigd door alienfruit op 27-05-2020 14:40 ]

[Ed Vertijsment]

alienfruit schreef op dinsdag 26 mei 2020 @ 18:20:
Hmm, dus je schrijft de API tests ook uit in bijv. Jest (als je TypeScript gebruikt) of NUnit? Een of andere manier had ik het idee dat er nieuwe oplossingen hiervoor waren. Andere projecten heb ik hiervoor supertest met Jest gebruikt.

We testen de API in de backend (Django) als unit tests en in de frontend (Karma, Mocha, Chai, Enzyme, Sinon) mocken we doorgaans de API weg. We testen doorgaans wel of de juiste URL is aangeroepen en simuleren dan een bepaalde response. Je hebt dan:

- Zekerheid dat je API werkt (backend)
- Zekerheid dat je API wordt aangeroepen (frontend)
- Zekerheid dat de output van je API resulteert in bepaald functionaliteit (frontend)

Hier zit nog wel het een en ander tussen, we gebruiken een zelf ontwikkelde library voor REST calls. Hiermee kunnen we ORM-style objecten manipuleren en saven, deze heeft zijn eigen testsuite die puurt uit unit tests bestaat (aangezien het een library is).

Overigens is op deze manier nog wel het een en ander aan te merken, ik heb ook een presentatie van een zekere dame gezien die haarfijn wist te vertellen dat elke mock je een stap verwijdert van de werkelijkheid en je tests dus minder betrouwbaar maakt. Daar zit in principe wel wat in. Het is altijd de afweging tussen een realistische test, performance van de test en onderhoud ervan.

alienfruit schreef op dinsdag 26 mei 2020 @ 18:20:
Ik snap het OTAP idee en heb hier ook eerder meegewerkt alleen probeer ook de Excel spreadsheet om te zetten naar een integratietoop zoals TestCafe of Cypress. Meestal zou ik dan de HTTP responses van de APIs mocken zodat de tests lekker snel zijn. Dit werkt wel. Alleen hier loop ik wel tegen wat dingen wat hoe je test OAuth oplossingen? Bijv. hoe wil je Google Login of Github login testen op deze manier? Als je de EULA leest van Google mag je eigenlijk geen bots gebruiken en neem aan dat Cypress/Selenium een bot?

Ik zou hier proberen om te kijken of je dit weg kan mocken, en als je afhankelijk bent van functionaliteit die weer variabel is voor die specifieke dependencies die cases proberen te isoleren en te testen/mocken tot de calls naar de externe API komen.

alienfruit schreef op dinsdag 26 mei 2020 @ 18:20:
Het probleem waar ik vaak tegen aan liep is dat de data toch iets anders is of werkt dan in de andere omgevingen bijv. door externe onderliggende systemen. Daarom had ik het idee of misschien na een release ook een setje tests te draaien in Productie en vervolgens na de test alleen datastore wijzigen terug te draaien. Als je event sourcing zou gebruiken dan kan je ook iets schrijven waar je events kan terugdraaien toch? Moet toegeven dat ik dat zelf nog nooit heb geprobeerd.

Doe dat alsjeblieft niet.

Draai NOOIT tests in productie en gebruik geen testinstellingen in productie. Ik zie al gelijk situaties als dit:

- Mails komen niet door want tijdelijk waren alle mails i.v.m. testsettings uitgeschakeld.
- Klanten krijgen allemaal mails want de tests checkt of dat werkt.
- Er staat op eens test records in de database door een Factory die tests objecten aanmaakten.
- Verschillende data is overschreven/aangepast/verloren omdat een test CRUD functionaliteit ging testen.
- De zooi is onbereikbaar want de test crasht of legt het systeem plat.

Doe dit gewoon niet, hang bij wijze een post it op om jezelf eraan te herinneren dat dit GEEN OPLOSSING is. Als je stack in je testomgeving anders is ligt het probleem bij je test stack, niet bij productie. Ga dan je productieomgeving na bouwen in je teststack.

Bij een vorige werkgever wordt dit laatste gedaan door een complete simulatie in te richten in docker en daar de tests in te draaien. Werkte prima.

[n9iels]

Ik houd bij het testen de alom bekende test piramide aan: veel unit testen, minder integratie testen en enkele E2E testen. Unit testen zijn super handig voor tijdens het ontwikkelen en snelle feedback. Hiervan kun je er eigenlijk niet genoeg hebben. Integratie testen zijn daar bovenop weer handig als er een database bij komt kijken. E2E testen zet ik het liefst zo breed mogelijk op en zijn echt het laatste redmiddel/zekerheid. Eigenlijk zouden deze niet moeten kunnen falen als de unit/integratie testen allemaal slagen.

Belangrijk om wel in te zien is dat een End-to-end test niet gelijk staat aan een UI test. Een UI kun je ook prima unit testen als dit gewenst is. Met name als we het hebben over een Angular of React front-end. Zo'n applicatie is qua complexiteit vandaag de dag gelijk, of misschien zelfs groter, dan de backend.

Wanneer je deze testen uit voert hangt een beetje af van hoe lang ze duren. In de basis wil je bij een Pull Request eigenlijk alle testen draaien. Als dit echt een groot issue wordt voor je development workflow zou je de keuze kunnen maken om de E2E testen bijv. enkel bij een PR naar master te draaien.

En tot slot, mijn ervaring is dat testen enkel goed werkt als je het compleet forceert. Dus stel in dat de "Merge" button van een PR uitgeschakeld is totdat de testen slagen. Mensen worden anders echt snel laks met als resultaat dat die laatste PR naar master 3x zo lang duur omdat niemand tussendoor naar de test output heeft gekeken.

[Hydra]

Ed Vertijsment schreef op dinsdag 26 mei 2020 @ 17:26:
Ten eerste wil je je test en productie omgevingen gescheiden houden, hier is OTAP voor, de exacte workflow wil nog wel is verschillen maar komt meestal neer op iets als:

• Ontwikkeling: jouw lokale machine waarop je werkt, lokaal tests draaien.
• Test: test/buildserver (bijvoorbeeld: Jenkins/Travis) waarop je automatisch alle tests draait en eventueel doorzet (handmatig of automatisch) naar een testomgeving waarop je rond kan klikken en de database vrij kan "vervuilen".
• Acceptatie: vergelijkbaar met een testomgeving maar dichterbij de werkelijkheid, voornamelijk zodat de klant kan testen.
• Productie: Afblijven (maar wel backups maken, en check of die compleet zijn.)

Ten eerste is de O in OTAP niet (perse) je eigen machine. De O is je primaire integratie omgeving waar de gemergde features voor het eerst bij elkaar komen. Developers hebben hier meestal volledige toegang toe, omdat je daar 't meest moet gaan rotzooien om uit te vogelen waarom feature A niet met feature B werkt. T is de technische test omgeving. A is de functionele test omgeving; dus waar gebruikers de bijna af versie testen. Productie spreekt voor zich.

Ten tweede is het niet zo dat je niet test op productie: het is de normaalste zaak om 'smoke tests' en 'performance regressie tests' te doen om alle omgevingen om te checken of de dingen ook op P nog werken zoals het hoort.

Ten derde; OTAP is helemaal de oplossing niet voor de vraag van @alienfruit. Het is een leuk en ietwat outdated manier van je verschillende omgevingen splitsen. Het komt tegenwoordig vaker voor dat omgeving ad-hoc opgespind worden als ze nodig zijn; (lang leve de cloud) dus dat onderscheid zie je eigenlijk vooral nog bij bedrijven die met eigen datacenters werken.

[alienfruit]

Ja, voor UI testing ben ik zelf een groot fan van Kent C Dodds' Testing Library wat erg fijn werkt om UI tests mee te schrijven. Ik ben het met jullie eens dat unit tests een goed begin punt, en dat wil ik ook graag vergroten in dit project. Ik ben het eens dat E2E niet zou mogen falen als de rest wel succesvol waren. Immers dan klopt er iets niet met de integratie tests. Dat volg ik wel.

Alleen ik denk dat het ook handig zou zijn als er wat tests worden gemaakt voor de APIs van externe partijen die we gebruiken zodat we zo snel mogelijk kunnen detecteren als ze dingen hebben veranderd. Je kent vast wel teams die graag hun APIs veranderd zonder de andere teams (bijv. Team A) binnen het bedrijf te verwittigen en je dus plots fouten hebt in productie of als je geluk hebt in preprod.

Volgens mij zou je hiervoor dan contract tests moeten schrijven? Het is duidelijk dat je dan toch echt met de API moet praten om te kijken of de verwachtte data terug komt. Het probleem wat ik heb is dat Team A graag uit het niets velden in de JSON toevoegt of verwijderd zonder ons dit te vertellen. Het verwijderen van een veld of het type veranderen (bijv. van integer naar een string) zorgt vervolgens dat de boel omvalt aan onze kant. Hoe lossen jullie zoiets op?

Er is al vaak gevraagd om ons te melden als ze wat veranderen, en OpenAPI specs vergelijken helpt ook niet omdat zie handmatig aanpassen en niet automatisch worden gegenereerd waardoor het detecteren op wijzigen van de spec niet echt werkt. Daarom wil ik graag aan onze kant alerts / monitoring in onze pipeline willen introduceren.

Ik moet aangeven dat de Team A voornamelijk wordt gebruikt om data te verzamelen wat vervolgens opslaan en vervolgens aanbieden via een meer eenduidig gestructureerde manier.

Misschien is mijn vraag meer als je een greenfield project begint en je moet met interne APIs praten zoals die van Team A hoe zou je je testing aanpakken. Wanneer je het liefst zo min mogelijk handmatig wil testen?

[Hydra]

alienfruit schreef op dinsdag 26 mei 2020 @ 13:30:
Ik vraag mij al enige tijd af wat de beste aanpak is voor het testen van een project en dan met name de backend. Mijn huidige aanpak tot nu toe is gelaagd middels:

1. End-to-end tests: Hier voer ik reeks een tests om te verifiëren om de beste functionaliteit werkt (e.g. user stories)
2. Unit tests: Tests van de functionaliteit per service / onderdeel
3. API tests: hierbij test ik handmatig de input-output van API endpoints middels een Postman collection

M.i. hanteer je niet de standaard benamingen van de test pyramid.

Mijn hele 'werk' is eigenlijk API's bouwen, soms met een front-end daarbij. De API testen we eigenlijk altijd geautomatiseerd; het is eigenlijk nooit nodig daar iets handmatig te doen. De unit en integration tests draaien tijdens de build. E2E tests draaien na de deploy op een test omgeving. Als het kan op een per-featurebranch omgeving; anders na een deploy op een bestaande omgeving.

Front-ends zijn wat lastiger om volledig automatisch te testen. Mijn insteek is dat wel zoveel mogelijk te doen omdat handmatig testen niet werkt. Als je 10 keer hetzelfde moet doen, ga je het de 11e keer overslaan. Dat is gewoon menselijk en ik zie het eigenlijk altijd. Voor front-end testing ben ik niet super op de hoogte maar lijkt Cypress een beetje de 'beste' tool te zijn.

Als je specifieke vragen hebt; let me know

[Hydra]

alienfruit schreef op woensdag 27 mei 2020 @ 17:17:
Volgens mij zou je hiervoor dan contract tests moeten schrijven? Het is duidelijk dat je dan toch echt met de API moet praten om te kijken of de verwachtte data terug komt. Het probleem wat ik heb is dat Team A graag uit het niets velden in de JSON toevoegt of verwijderd zonder ons dit te vertellen. Het verwijderen van een veld of het type veranderen (bijv. van integer naar een string) zorgt vervolgens dat de boel omvalt aan onze kant. Hoe lossen jullie zoiets op?

Er is al vaak gevraagd om ons te melden als ze wat veranderen, en OpenAPI specs vergelijken helpt ook niet omdat zie handmatig aanpassen en niet automatisch worden gegenereerd waardoor het detecteren op wijzigen van de spec niet echt werkt. Daarom wil ik graag aan onze kant alerts / monitoring in onze pipeline willen introduceren.

Je zou eens naar contract based testing moten kijken dmv van bijvoorbeeld Pact. Het werkt erg goed. Het lastige is vooral om het ergens naar binnen te kijken, omdat het relatief onbeperkt is, het HEEL duidelijk maakt als je iets fout doet, en testen voor veel developers die ad hoc changes doen sowieso een vies woord is.

[alienfruit]

@Hydra Bedankt, ik ga eens kijken naar Pact. Heb je er zelf ervaring mee? Het ziet er veel belovend uit na het lezen van de 5-minutes guide. Een oplossing zou zijn om zelf pacts te schrijven voor de api van Team A met de aannames hoe deze API werkt en hoe je het momenteel gebruikt in je eigen project. Vervolgens kan je het dan altijd draaien tegen hun endpoint en als de boel weer eens over hoop is gehaald zou je dit meteen kunnen detecteren. Wanneer draai je zulke Pact verificatie tests dan?

[supersnathan94]

Eh is dat zo @Hydra ? In het engels is het DTAP en dekt misschien beter de lading -> Dev.

Verder is het erg handig om te weten wat voor packaging TS gebruikt. Wij gebruiken bijvoorbeeld docker en K8S en draaien hiervoor dus een Postman collectie tegen een docker image aan die bepaalde data kan aanspreken. Hierdoor spinnen we het hele platform in de lucht en kunnen we per commit ook de gehele API testen op daadwerkelijke inhoud en niet alleen op interface niveau.

Dus wat is je huidige stack? Wat wil je automatiseren en vooral waarom? Welke patformen heb je ter beschikking en wat zou je kunnen gebruiken voor scheiding van omgevingen? Heb je ervaring met docker of K8s en wil je dit hier kunnen inzetten?

Hoe pakken jullie het testen aan? Vooral als je geen echte QA persoon in je team hebt?

Tester is een rol niet per se een persoon. Gebruik de kennis die je hebt en vraag je af wat nuttig is om te testen. Unittests is bijvoorbeeld altijd een must. Puur om op component niveau te kunnen garanderen dat een refactorslag de boel niet kapot maakt. Integratietests doe je om te kijken wat er gebeurt als een afnemer een call doet die niet klopt. heb je je exception handling wel goed op orde of crashed de hele boel? Ketentests zijn nuttig om de hele stack van voor tot eind in de gaten te kunnen houden, komt mijn input er wel juist uit? En wat als de input fout is? Krijg ik dit er dan ook zo uit (SISO) of krijg ik aan de achterkant een validatiefout terug?


Ik wil je nog even wijzen op een artikel van iemand waar ik mee samengewerkt heb met wat uitleg over restful API testing en hoe het kadaster dit georganiseerd heeft.
https://nljug.org/java-ma...fied-with-docker-compose/

[Ed Vertijsment]

Hydra schreef op woensdag 27 mei 2020 @ 17:13:
[...]


Ten eerste is de O in OTAP niet (perse) je eigen machine. De O is je primaire integratie omgeving waar de gemergde features voor het eerst bij elkaar komen. Developers hebben hier meestal volledige toegang toe, omdat je daar 't meest moet gaan rotzooien om uit te vogelen waarom feature A niet met feature B werkt. T is de technische test omgeving. A is de functionele test omgeving; dus waar gebruikers de bijna af versie testen. Productie spreekt voor zich.

Ik hoopte discussies over de exacte definitie voor te zijn, zie ook:

Ed Vertijsment schreef op dinsdag 26 mei 2020 @ 17:26:
de exacte workflow wil nog wel is verschillen

Maar dat was helaas niet duidelijk. Het komt vaker voor dat bepaalde termen, of het nou OTAP, MVC, REST of iets anders theoretisch heel exact beschreven zijn maar in de praktijk een wat lossere definitie hebben. Het lijkt me niet waardevol om hier een discussie over te gaan voeren.

Hydra schreef op woensdag 27 mei 2020 @ 17:13:
[...]
Ten tweede is het niet zo dat je niet test op productie: het is de normaalste zaak om 'smoke tests' en 'performance regressie tests' te doen om alle omgevingen om te checken of de dingen ook op P nog werken zoals het hoort.

Oh ja, ik ken iemand die voor Facebook hele datacenters uit mag zetten om te kijken of alles doorgaat als dat gebeurt, maar dat is natuurlijk wat anders dan je unit tests afschieten op een productie omgeving. Dus in de breedste zin van het woord, Ja, je test productie, al is het maar om te zien of 'ie up is, maar je draait geen unit tests er tegen aan.

Hydra schreef op woensdag 27 mei 2020 @ 17:13:
[...]
Ten derde; OTAP is helemaal de oplossing niet voor de vraag van @alienfruit. Het is een leuk en ietwat outdated manier van je verschillende omgevingen splitsen. Het komt tegenwoordig vaker voor dat omgeving ad-hoc opgespind worden als ze nodig zijn; (lang leve de cloud) dus dat onderscheid zie je eigenlijk vooral nog bij bedrijven die met eigen datacenters werken.

Zie ook:

Ed Vertijsment schreef op dinsdag 26 mei 2020 @ 17:26:
Je wilt dus vooraal op je build server aan de gang. Zeker niet op productie.

Ik wou eigenlijk hier aangeven waar je aan de slag wilt

En ja, tegenwoordig spin je gewoon ad-hoc ff een container/server/iets anders op om mee te testen maar dat is nog steeds niet de bak die in productie staat. Het feit dat je je andere techniek gebruikt betekent niet dat je opeens niet meer andere omgevingen hebt om mee aan de slag te gaan. Ook al hoeven ze niet meer altijd te draaien. Nogmaals de schoolvoorbeelden van OTAP zullen technisch misschien niet (altijd) meer relevant zijn maar het achterliggende gedachtegoed is onveranderd gebleven.

Zie ook mijn tweede post, in het verleden gewerkt met productie-like containers die werden opgespind bij de tests. Werkte prima.

[alienfruit]

Mijn stack is Google Cloud met Firestore (Datastore mode), Kubernetes Cluster, met een reeks Typescript/Node RESTful servers die aan elkaar worden geknopt middels Google PubSub en de RESTful APIs wordt via Kong aan elkaar geknoopt. Naast deze API is er nog een Next.js gebaseerd web UI. Er wordt gebruik gemaakt van Gitlab voor de package and container registry, en Gitlab Pipelines voor het bouwen van de npm packages en docker images. De unit tests gedraaid voor de RESTful services en enkele Cypress E2E tests (middels mocks) voor de web UI.

Ik denk dat mijn onduidelijk voornamelijk zit bij de afhankelijkheden met derde partijen (Google Login, externe data providers e.d.) en hoe je zekerheden kan inbouwen en/of automatiseren dat je met redelijke vertrouwen continue kan deployeer naar productie en/of de testomgeving. En dus fouten qua configuratie Google Login of bijv. onderliggende APIs die we in onze eigen RESTful servers gebruiken veranderen zonder dat we het weten.

Mijn ervaring in het verleden met SAP en FinTech is dat er altijd een soort van blocker op het testen zit qua de beschikbaar tijd en de te testen functionaliteit/pull requests door de QA persoon. Daarom vraag ik mij af hoe je deze blocker kan beperken. De huidige handmatige test cases kan eigenlijk wel geautomatiseerd worden middels Cypress.

Als je een greenfield project met zoiets als hierboven wat zou dan je droom opzet zijn?

Dank je wel voor het artikel ik ga het zometeen eens lezen

[ Voor 19% gewijzigd door alienfruit op 27-05-2020 20:23 ]

[Voutloos]

Waarom die focus op externen?

Als je 1x weet dat een send naar je Mailgun werkt, moet je gewoon op de rest vertrouwen.

Sterker nog: Als een externe API backward compatibility onaangekondigd breekt, is dat géén technisch issue. De oorzaak heeft dan ook geen technische fix. Sure, je hebt misschien een hotfix nodig voor het symptoom van het incident vd dag. Maar, het echte probleem is slechte discipline, stijl en/of commmunicatie van de externe partij en daar gaat geen techniek je bij helpen.

[Hydra]

alienfruit schreef op woensdag 27 mei 2020 @ 17:28:
@Hydra Bedankt, ik ga eens kijken naar Pact. Heb je er zelf ervaring mee? Het ziet er veel belovend uit na het lezen van de 5-minutes guide. Een oplossing zou zijn om zelf pacts te schrijven voor de api van Team A met de aannames hoe deze API werkt en hoe je het momenteel gebruikt in je eigen project. Vervolgens kan je het dan altijd draaien tegen hun endpoint en als de boel weer eens over hoop is gehaald zou je dit meteen kunnen detecteren.

Ja, het werkt echt top. Het probleem is niet de technologie, het probleem is dat het je 'dwingt' serieus na te denken over API changes en dat levert nogal wat weerstand op bij de gemiddelde YOLO dev.

Wanneer draai je zulke Pact verificatie tests dan?

Wij hadden het geintegreerd in de build.

[Hydra]

supersnathan94 schreef op woensdag 27 mei 2020 @ 17:29:
Eh is dat zo @Hydra ? In het engels is het DTAP en dekt misschien beter de lading -> Dev.

Nouja, wel in mijn ervaring. Heb echt nog nooit iemand eerder horen zeggen dat de O/D in OTAP/DTAP je eigen machine is.

Het kan prima zijn dat je geen volledige OTAP straat hebt, dus bijvoorbeeld alleen A en P, maar dan 'doe' je dus geen OTAP.

[supersnathan94]

Ok ik ken genoeg bedrijven waar dat toch anders gezien wordt dan. Als ik wikipedia er zo op nakijk wordt het juist ook op die manier gebruikt:

Wikipedia: OTAP --> ontwikkelomgeving
Wikipedia: Development, testing, acceptance and production --> Development system. This development environment might have no testing capabilities.

In mijn ervaring is de O/D iig geen losse omgeving waar je "alleen" naartoe gaat om te integreren. Opzich snap ik jouw redenatie ook wel dat het niet per se jouw machine hoeft te wezen, want het kan ook prima remote zijn bijvoorbeeld), maar in heel veel scenario's wordt het wel gezien als je ontwikkel omgeving.

Ik ben wel met je eens dat het allemaal wat meer door elkaar is gaan lopen met de verclustering van services en dat je vaak niet meer het onderscheid hebt in fysiek gescheiden omgevingen, maar dat je on demand iets neer kunt zetten. OTAP is in dat opzicht dan ook een beetje achterhaald afhankelijk van de cultuur waar je in werkt. (volledig DevOps in de Cloud is anders dan scrum Dev on-premise eg maar).


Maar even een uit nieuwsgierigheid. Als de O/D niet je eigen machine zou zijn, hoe noem jij dan je eigen machine wel en wat doe je daar dan op? Puur en alleen het code kloppen of hoe moet ik dat zien?

[Gomez12]

Voutloos schreef op donderdag 28 mei 2020 @ 11:46:
Waarom die focus op externen?

Als je 1x weet dat een send naar je Mailgun werkt, moet je gewoon op de rest vertrouwen.

Sterker nog: Als een externe API backward compatibility onaangekondigd breekt, is dat géén technisch issue. De oorzaak heeft dan ook geen technische fix. Sure, je hebt misschien een hotfix nodig voor het symptoom van het incident vd dag. Maar, het echte probleem is slechte discipline, stijl en/of commmunicatie van de externe partij en daar gaat geen techniek je bij helpen.

Tja, als dit je mening is, waarom dan uberhaupt nog testen? Waarom niet gewoon yolo je code live gooien?

Elke refactoring buiten de jou toegekende classes etc zijn dan immers slechte discipline, stijl en/of communicatie.
Sterker nog, bugs binnen je eigen code (ook al is het in de nieuwe classes) zijn nog steeds slechte discipline, stijl en/of communicatie...

Kijk, wij gaan ervanuit dat een mens per definitie slecht is in discipline, stijl en/of communicatie en daarom testen wij. Maar als je dat overboord wilt gooien voor externe API's waarom dan niet voor alles?

[BCC]

Je moet zoveel testen dat je build failed als er iets stuk is en zo weinig testen dat je ci snel is en niet voor elke kleine refactor een hele bak Tests moet wijzigen.

[armageddon_2k1]

Gomez12 schreef op donderdag 28 mei 2020 @ 21:40:
[...]

Tja, als dit je mening is, waarom dan uberhaupt nog testen? Waarom niet gewoon yolo je code live gooien?

Elke refactoring buiten de jou toegekende classes etc zijn dan immers slechte discipline, stijl en/of communicatie.
Sterker nog, bugs binnen je eigen code (ook al is het in de nieuwe classes) zijn nog steeds slechte discipline, stijl en/of communicatie...

Kijk, wij gaan ervanuit dat een mens per definitie slecht is in discipline, stijl en/of communicatie en daarom testen wij. Maar als je dat overboord wilt gooien voor externe API's waarom dan niet voor alles?

Omdat je controle hebt over je eigen API’s en niet over die van externen en je dus overgeleverd bent aan de professionaliteit van de derde partij.

Het enige wat een test van een externe API je oplevert is dat je op dat ene moment weet dat als het stuk gaat het niet aan jou ligt. Dat is overigens best waardevol. Als productie eruit klapt en je zoekt je een apelazarus is het wel handig als je een externe test suite kan draaien om te kijken of het aan jou ligt of niet.

[Hydra]

supersnathan94 schreef op donderdag 28 mei 2020 @ 17:05:
Maar even een uit nieuwsgierigheid. Als de O/D niet je eigen machine zou zijn, hoe noem jij dan je eigen machine wel en wat doe je daar dan op? Puur en alleen het code kloppen of hoe moet ik dat zien?

Je eigen machine is gewoon je eigen machine.

Je neemt dat "wordt ontwikkeld op een ontwikkel omgeving" te letterlijk. De O is niet de plek waar je de code typt, het is de plek waar alle 'shit' draait die je nodig hebt om de eerste tests te kunnen doen. Vergeet niet dat dit bedacht is voor grote 'enterprise' omgevingen die simpelweg te groot zijn om allemaal op je eigen machine te draaien. Als je servce indirect afhankelijk is van 5 andere services, 2 databases en een enterprise bus, dan wil je een "O" omgeving. Als je een laravel site bouwt met gewoon een MySQL DB eronder die samen prima op je laptop draaien, heb je geen "OTAP" nodig.

[Gomez12]

Hydra schreef op vrijdag 29 mei 2020 @ 09:28:
[...]


Je eigen machine is gewoon je eigen machine.

Je neemt dat "wordt ontwikkeld op een ontwikkel omgeving" te letterlijk. De O is niet de plek waar je de code typt, het is de plek waar alle 'shit' draait die je nodig hebt om de eerste tests te kunnen doen.

Ehm, denk ik zo verkeerd als ik zeg dat ik de 1e tests doe door op F5 / Run te drukken?

Die 500Gb dbases etc die zijn gewoon veelal te verkleinen naar 5Gb dbases die ik wel lokaal kan draaien en voor de hoeveelheid systemen hebben we toch docker / vagrant etc. Zodat ik die even kan opstarten.

En ja, dat is dan nog geen real-life test omdat er niet met real-life groottes etc gewerkt wordt, maar daarvoor heb je ook de T-fase die vind buiten je eigen systeem plaats tegen real-life relevante data.

[supersnathan94]

Als je servce indirect afhankelijk is van 5 andere services, 2 databases en een enterprise bus, dan wil je een "O" omgeving

Euhm nee? Daar is je test omgeving voor.

Ehm, denk ik zo verkeerd als ik zeg dat ik de 1e tests doe door op F5 / Run te drukken?

Nee. dat is het bij mij ook.

Indirecte afhankelijkheden mock je weg toch? Die behandel je voor dat component als 3rd party en daar heb je interface afspraken over. Je kunt dit eventueel nog aftesten in een ketentest (geen slecht idee).

Als je een laravel site bouwt met gewoon een MySQL DB eronder die samen prima op je laptop draaien, heb je geen "OTAP" nodig.

Ik ken genoeg systemen/services die lokaal op mijn laptop prima draaien, maar wel gewoon een OTAP straat nodig hebben hoor. Het is niet alleen of het technisch noodzakelijk is, maar ook gewoon proces afspraken om bepaalde kwaliteit te kunnen garanderen. Met de huidige technologische ontwikkelingen zijn servers niet meer de apparaten die je nodig hebt om wat simpele dingen op te draaien. Met docker op een leuk workstation kun je vrijwel alles draaien. Een kleine test database eronder en je kunt aan de gang.

[alienfruit]

Dank je wel voor alle feedback, ik ben er nog niet helemaal uit wat de beste aanpak is. Maar ik heb de volgende aandachtspunten voor nu om het project wat te verbeteren:

• Striktere controle dat er unit tests zijn voor de services en de webapplicatie
• Simpeler om het project uit te checken, misschien alle services in een repo plaatsen of een CLI tool bouwen om hiermee te helpen e.g. `tool dev` of `tool staging` zodat de boel in de omgeving draait
• Uitzoeken of het mogelijk is om gemakkelijk Firestore en PubSub lokaal te draaien middels de emulatoren voor een betere lokale nabootsing
• Mogelijk bespreken om PACT te gebruiken met de andere teams en/of externe partijen voor betere detectie wanneer de boel weer eens veranderd
• Cypress tests voor het omzetten van de handmatige testplan zodat het voor elke merge naar master wordt getest ipv na elke sprint
• Mogelijkheid onderzoeken in hoeverre het zin heeft om iets als Garden Kubernetes te gebruiken
• Automatiseren/schrijven van Cypress tests van de handmatige testplan en die vervolgens draaien met mocking voor PRs
• Test draaien middels TestCafe voor IE11 om te kijken of we niet te maken hebben de white screen of death tijdens PRs
• Smoke test draaien na release naar Staging en Prod om te kijken om de basisfunctionaliteit nog werkt zoals inloggen en door de pagina klikken zonder mocks

Ik zit alleen te kijken of het de moeite waard is om een bepaalde set van tests op basis van een wachtrij te doen ipv parallel omdat het lastig om bij parallel draaien het lastig om de database te resetten.

[ Voor 6% gewijzigd door alienfruit op 29-05-2020 11:10 ]

[Hydra]

Gomez12 schreef op vrijdag 29 mei 2020 @ 10:40:
[...]

Ehm, denk ik zo verkeerd als ik zeg dat ik de 1e tests doe door op F5 / Run te drukken?

Die 500Gb dbases etc die zijn gewoon veelal te verkleinen naar 5Gb dbases die ik wel lokaal kan draaien en voor de hoeveelheid systemen hebben we toch docker / vagrant etc. Zodat ik die even kan opstarten.

Ik heb het niet over grote databases maar over grote architecturen. Denk aan een bank waarbij ik weet niet hoeveel systemen samen werken. Die kun je niet samen op je laptop draaien. Je het gewoon letterlijk het geheugen niet om 50 services, 10 databases en 5 queue systemen te draaien. Dus om te kijken of je shizzle, naast je eigen integration tests waar je externe dependencies mockt, daadwerkelijk werkt heb je een 'echte' omgeving nodig waar dat wel op draait. En de eerste omgeving waar je dat op doet is over het algemeen een van de O omgevingen.

[Hydra]

supersnathan94 schreef op vrijdag 29 mei 2020 @ 10:50:
Euhm nee? Daar is je test omgeving voor.

De T in OTAP is meestal de omgeving waar alles van verschillende teams op samenkomt. Het is net zoals de O/D een test-omgeving. Maar vaak is er per team een O, en dan per afdeling (bijvoorbeeld) een T. De projecten waar ik het over heb, heb je dus 10 D omgevingen, 2-4 T omgevingen, 2 A omgevingen en 1 P omgeving. Wat ik ook wel eens gezien heb, was dat A en P per release omgedraaid werden, dus na een release was A P en vice versa.

Er zijn veel verschillende interpretaties van OTAP en het verschilt nogal kwa grootte en complexiteit, maar het klopt gewoon niet te stellen dat "O" je eigen machine is. Of nouja; je mag het van mij prima zo noemen, maar als je dat vrolijk bij de IND of ING gaat verkondingen ga je wat vreemd aangekeken worden vermoed ik zo.

Indirecte afhankelijkheden mock je weg toch? Die behandel je voor dat component als 3rd party en daar heb je interface afspraken over. Je kunt dit eventueel nog aftesten in een ketentest (geen slecht idee).

Tuurlijk. Maar dat betekent niet dat je het niet test. Dat is gewoon nodig. Mensen maken fouten; daarom testen we. De meeste services waar ik aan werk, werken met integration tests in de build. Maar daarna worden ze gedeployed en worden er zowel op de O als T omgevingen geautomatiseerde E2E tests gedraaid.

Ik ken genoeg systemen/services die lokaal op mijn laptop prima draaien, maar wel gewoon een OTAP straat nodig hebben hoor.

Ik snap je punt niet. Ik zeg dat er veel complexe architecturen zijn die je gewoon niet integraal op je eigen machine kan draaien. Ik zeg nergens het tegenovergestelde.

Meestal kun je een service lokaal opstarten en dan tegen (bijvoorbeeld) een O omgeving aan laten praten. Vaak kan dat met T al niet, omdat die al van buiten niet te benaderen zijn (T is een technische test omgeving, dus ook netwerk configuraties moeten dan al redelijk productie-like zijn). Dan zie je dus bijvoorbeeld dat op de O omgeving er geen certificaten nodig zijn, maar dat op T al mutual TLS aanstaat bijvoorbeeld.

[supersnathan94]

Het heeft niet zoveel zin om hier heel uitgebreid die discussie te gaan lopen voeren want dat is wel degelijk off topic.

Ik wil er nog een paar woorden over kwijt maar daarna vind ik zelf dat we weer beter kunnen gaan kijken naar wat TS noou precies nodig heeft ipv semantiek .

Er zijn veel verschillende interpretaties van OTAP en het verschilt nogal kwa grootte en complexiteit, maar het klopt gewoon niet te stellen dat "O" je eigen machine is. Of nouja; je mag het van mij prima zo noemen, maar als je dat vrolijk bij de IND of ING gaat verkondingen ga je wat vreemd aangekeken worden vermoed ik zo.

Ik zeg ook niet dat het per se lokaal is. Op dat punt geef ik je 100% gelijk. Het kan ook prima een VDI zijn of iets anders. Ook is het inderdaad afhankelijk van complexiteit en kwantiteit van de services. De definitie van "dev/Ontwikkel" omgeving binnen OTAP geeft echter expliciet aan dat het echt bedoeld is voor ontwikkeling en dat het dus niet per se zo hoeft te zijn dat er ook test mogelijkheden aanwezig zijn. Een laptop kan per definitie dus al voldoen aan dat requirement. Zo wordt het dan ook in heel veel grote organisaties wel degelijk gebruikt. Ook bij banken. Niet altijd hoor, want ook zij kijken verder dan alleen ff ohja we doen dat even erbij. Het moet wel nuttig zijn. Bij Rabo zijn ze bijvoorbeeld ook al grotendeels bezig met testen in productie waarmee je dus direct een groot deel overslaat (van develop lokaal naar productie omgeving deployen). Hoe ik dat weet? Nou heel simpel. ik heb daar ook collega's werken en Rabo developers staan toch vaak op de grote conferenties zoals die van NLJUG en Devcon van Luminis. Ik deel het stuk dat je er bij een grote bank niet mee wegkomt dan ook totaal niet. Ook banken hebben afwijkende opstellingen en met dev wordt in dergelijke presentaties wel degelijk lokale machines mee bedoeld.

Zie ook dit stukje van ITpedia: https://www.itpedia.nl/20...wikkelen-van-applicaties/

Ik snap je punt niet. Ik zeg dat er veel complexe architecturen zijn die je gewoon niet integraal op je eigen machine kan draaien. Ik zeg nergens het tegenovergestelde.

Jij zegt vrij letterlijk het volgende:

Als je een laravel site bouwt met gewoon een MySQL DB eronder die samen prima op je laptop draaien, heb je geen "OTAP" nodig.

Het is vrij normaal om ook voor kleine projecten wel degelijk die fases door te lopen zodat je ook afzonderlijk bepaalde dingen kan doen. Zoals schakelen met de klant in Accceptatie omgeving terwijl iemand anders bezig is met exploratory testing op een test omgeving voor nieuwe features.

Maar enfin er zijn dus ontzettend veel mogelijkheden die per bedrijf en vaak ook nog eens per team verschillen. Om ze over 1 kam te scheren gaat dan ook een beetje ver. Het ging mij er ook een beetje om het inzicht te verkrijgen wat je nu precies bedoelde. Ik (en anderen) hanteren namelijk andere definities van deze manier van werken en zien onze eigen ontwikkel omgeving lokaal dan ook als O binnen OTAP, Misschien onterecht, maar tot op heden ben jij de eerste die me een andere interpretatie hebt laten zien, dus bedankt voor het delen iig.

Ik zit alleen te kijken of het de moeite waard is om een bepaalde set van tests op basis van een wachtrij te doen ipv parallel omdat het lastig om bij parallel draaien het lastig om de database te resetten.

Heb je de mogelijkheid om de software in docker te hangen? Want dan kun je namelijk voor iedere set aan tests een set containers opspinnen.

[Kalentum]

alienfruit schreef op vrijdag 29 mei 2020 @ 11:03:
Ik zit alleen te kijken of het de moeite waard is om een bepaalde set van tests op basis van een wachtrij te doen ipv parallel omdat het lastig om bij parallel draaien het lastig om de database te resetten.

Wat wij doen is na elke test de database resetten. Dat kan op verschillende manieren. Bv de test runt in een database transactie en die transactie wordt niet gecommit. Of alle tabellen truncaten.

Hierdoor kun je tests in parallel runnen op 1 database want die transacties worden nooit gecommit en de verschillende tests zien elkaar niet

[Hydra]

supersnathan94 schreef op zaterdag 30 mei 2020 @ 19:13:
Het heeft niet zoveel zin om hier heel uitgebreid die discussie te gaan lopen voeren want dat is wel degelijk off topic.

Ik wil er nog een paar woorden over kwijt maar daarna vind ik zelf dat we weer beter kunnen gaan kijken naar wat TS noou precies nodig heeft ipv semantiek .

Melden dat het offtopic is maar dan wel graag het laatste woord willen hebben in een discussie vind ik nogal kinderachtig. Net zoals de rest van je post; waar ik op reageerde was heel simpel dat de "O" in OTAP over het algemeen niet je eigen machine is. Ik redeneer zelf simpelweg vanuit 18+ jaar persoonlijke ervaring in projecten bij grote organisties die (toen nog) via OTAP werken.

Zoals ik aangaf; tegenwoordig is het anders omdat het opspinnen van VMs veel simpeler is. Dus die terminologie wordt ook steeds minder gebruikt omdat het outdated is.

In de gangbare definitie is de O in OTAP gewoon niet je eigen machine. Klaar. Dat is waar ik op reageerde. En als het daar niet mee eens bent; be my guest, maar ik ga hier geen tijd meer aan besteden. En al helemaal niet aan iemand die het onderwerp probeert te draaien naar iets wat in z'n straatje past.

Je werkt net een jaar of 3 man...komop.

[Giesber]

Hydra schreef op maandag 1 juni 2020 @ 11:01:
[...]


Melden dat het offtopic is maar dan wel graag het laatste woord willen hebben in een discussie vind ik nogal kinderachtig.

Om dan te reageren met exact hetgeen wat je al eens gezegd hebt. Om toch maar het laatste woord te hebben?

Zoals ik aangaf; tegenwoordig is het anders omdat het opspinnen van VMs veel simpeler is. Dus die terminologie wordt ook steeds minder gebruikt omdat het outdated is.

Een VM die je even opspint kan toch nog altijd een test of accept omgeving zijn? Niemand zegt dat een acceptatie omgeving up and running moet zijn als niemand ze gebruikt. OTAP bestaat nog altijd op veel plaatsen, alleen zijn er soms hipsters die er per se een andere naam aan willen geven.

In de gangbare definitie is de O in OTAP gewoon niet je eigen machine. Klaar.

Niet klaar, dat is soms wel een eigen machine. Of pas anders de Engelse Wikipedia aan, en kijk eens hoe lang je wijziging daar blijft staan.

Je werkt net een jaar of 3 man...komop.

vind ik nogal kinderachtig.

[Croga]

BCC schreef op donderdag 28 mei 2020 @ 21:55:
Je moet zoveel testen dat je build failed als er iets stuk is en zo weinig testen dat je ci snel is en niet voor elke kleine refactor een hele bak Tests moet wijzigen.

Voor een refactor hoef je nooit een test te wijzigen. De hele definitie van een refactor is dat de functionaliteit niet verandert, alleen de constructie daarvan. De truuk van een refactor is dan ook dat als de test faalt, je refactor niet goed is.

[Ed Vertijsment]

Croga schreef op maandag 1 juni 2020 @ 23:15:
[...]

Voor een refactor hoef je nooit een test te wijzigen. De hele definitie van een refactor is dat de functionaliteit niet verandert, alleen de constructie daarvan. De truuk van een refactor is dan ook dat als de test faalt, je refactor niet goed is.

Met de theorie ben ik het 100% met je eens. In de praktijk wil hier nog wel eens wat anders uitkomen, bijvoorbeeld omdat je en specifieke iets uit de oude situatie hebt gemocked dat niet meer aanwezig is.

[Croga]

Ed Vertijsment schreef op dinsdag 2 juni 2020 @ 10:08:
Met de theorie ben ik het 100% met je eens. In de praktijk wil hier nog wel eens wat anders uitkomen, bijvoorbeeld omdat je en specifieke iets uit de oude situatie hebt gemocked dat niet meer aanwezig is.

Dan is het geen refactor. Dan is het een aanpassing.

[Ed Vertijsment]

Croga schreef op dinsdag 2 juni 2020 @ 10:17:
[...]

Dan is het geen refactor. Dan is het een aanpassing.

Is dat zo? Het kan prima een nafactor zijn als je alleen de private API herziet. Je hoeft niet natuurlijk 100% dezelfde structuur te behouden qua classes/functies tenzij je het exposed naar derden.

[Croga]

Ed Vertijsment schreef op dinsdag 2 juni 2020 @ 10:29:
Is dat zo? Het kan prima een nafactor zijn als je alleen de private API herziet. Je hoeft niet natuurlijk 100% dezelfde structuur te behouden qua classes/functies tenzij je het exposed naar derden.

Volgens Uncle Bob is dat zo. Volgens Uncle Bob en het TDD concept Red-Green-Refactor kan een refactor er nooit voor zorgen dat een unit test aangepast moet worden.

[Ed Vertijsment]

Croga schreef op dinsdag 2 juni 2020 @ 10:32:
[...]

Volgens Uncle Bob is dat zo. Volgens Uncle Bob en het TDD concept Red-Green-Refactor kan een refactor er nooit voor zorgen dat een unit test aangepast moet worden.

Meh fair enough. Het is natuurlijk het mooiste als dat nooit nodig zou zijn. Maar het blijf IMO een theoretisch iets dat soms met een korreltje zout genomen moet worden. Maar dat hangt dan ook weer van je project af.

Het herzien van een private API kan mijn inziens gewoon bij een refactor horen. En daar kunnen in sommige gevallen aangepast tests bij komen kijken (zie de opmerking over mocks). Dat dit een "liever niet" scenario is, eens. Maar in de praktijk is het soms echt wel zo en als ik kan kiezen tussen 3 tests aanpassen of code niet kunnen verbeteren kies ik voor 3 tests aanpassen. Tevens vind ik het prima als bij een refactor de private api of structuur van een klasse/functie onderhanden wordt genomen. Het belang van betere code gaat dan even voor de wens om tests niet te hoeven aanpassen.

[Croga]

Ed Vertijsment schreef op dinsdag 2 juni 2020 @ 10:39:
Het herzien van een private API kan mijn inziens gewoon bij een refactor horen. En daar kunnen in sommige gevallen aangepast tests bij komen kijken (zie de opmerking over mocks). Dat dit een "liever niet" scenario is, eens.

Och, volgens mij is het een semantiek "probleem", geen real-world problem :-) Dus mee eens, als dat nodig is dan is dat nodig maar officieel ben je dan niet meer aan het refactoren maar aan het aanpassen

[alienfruit]

Kalentum schreef op zaterdag 30 mei 2020 @ 20:19:
Wat wij doen is na elke test de database resetten. Dat kan op verschillende manieren. Bv de test runt in een database transactie en die transactie wordt niet gecommit. Of alle tabellen truncaten.

Hierdoor kun je tests in parallel runnen op 1 database want die transacties worden nooit gecommit en de verschillende tests zien elkaar niet

Interessant idee, ik ga eens kijken of Google Datastore zoiets ondersteunt. Bij zo'n werkwijze die je beschrijft moet de database wel lekker primary keys e.d. op de juist 'opslaan' en dit half werk doen tot dat je de transactie commit. Ik heb dat wel eens eerder gezien. Google Datastore/Firestore documentatie hier niet echt duidelijk in.

[Kalentum]

alienfruit schreef op dinsdag 2 juni 2020 @ 13:26:
[...]


Interessant idee, ik ga eens kijken of Google Datastore zoiets ondersteunt. Bij zo'n werkwijze die je beschrijft moet de database wel lekker primary keys e.d. op de juist 'opslaan' en dit half werk doen tot dat je de transactie commit. Ik heb dat wel eens eerder gezien. Google Datastore/Firestore documentatie hier niet echt duidelijk in.

Bij ons is het voornamelijk MySQL. En als je een record insert in een tabel met autoincrements voor primary keys en je commit niet (ROLLBACK) dan wordt dat id niet opnieuw uitgegeven. Dus dat gaat wel goed.

En developers moeten natuurlijk hun tests goed schrijven: niet aannemen dat een bepaalde INSERT een bepaalde ID oplevert. Wat bij ons sowieso niet kan, want de tests worden in willekeurige volgorde uitgevoerd: elke run is anders.

[alienfruit]

Ja, klopt, ik snap dat je de aanname van en bepaalde ID niet moet nemen. Ik weet alleen niet zeker in hoeverre de IDs al worden weggeschreven. Het lijkt op dat er tweestaps is bijv. alleen deel van de ID wordt geschreven binnen de transactie en de totale ID pas bij commit. Maar daar moet ik nog wat betere documentatie over vinden.