Tag web development

De leercurve van Angulartests beklimmen - deel 4

Wat is de kern van ons onderhoudprobleem? Codeduplicatie - of liever: de duplicatie van informatie. Het opzetten van een bepaalde service en haar afhankelijkheden gebeurt voor elke (reeks) test(en) handmatig in de beforeEach-methode. Als dezelfde afhankelijkheid in twee verschillende reeks testen voorkomt, moet de ontwikkelaar deze twee keer uitschrijven. Maar is dat nu echt nodig?

De leercurve van Angulartests beklimmen - deel 3

Hoe onderhoudbaar was onze testopzet? Onze services verwachtte niet één afhankelijkheid, maar wel vijf of zes of zeven - en soms zelfs meer. En die afhankelijkheden verwachtten op hun beurt ook weer vijf, zes, zeven afhankelijkheden. Het was niet ondenkbaar dat een ontwikkelaar langer bezig zou zijn met het opzetten van al die afhankelijkheden om zijn test te laten compileren, dan het daadwerkelijk verifiëren van het gedrag van het stukje code waar hij in was geïnteresseerd.

De leercurve van Angulartests beklimmen - deel 2

In een vorige blog beschreef ik de keuze van mijn team om de front end van onze Angular-applicatie te testen via end to end-tests - en waarom we daar uiteindelijk op terugkwamen. Nu we besloten hadden inderdaad te willen (nee, moeten) unit testen, doemde er een nieuwe keuze op in de beslisboom: gaan we ons in het zweet werken om Angulars steile leercurve te beklimmen, of bekijken we of er een manier is waarop we het testen voor ons kunnen vergemakkelijken?

De leercurve van Angulartests beklimmen - deel 1

Niet lang nadat we Angular als front end-framework besloten te gebruiken, maakten we de keuze de unit tests te laten voor wat het was. We waren heus wel overtuigd van het belang ervan, dat was het probleem niet, maar de stijle leercurve van Angulars tests verleidde ons daar niet naar te handelen. Toch lieten we het testen van de front end niet helemaal schieten. Onze tester had zich verdiept in end to end testframework Selenium, en het team wilde graag geloven dat dit een acceptabel alternatief was voor het schrijven van front end tests. Maar uiteindelijk dwong de werkelijkheid ons toch die beslissing te herzien.

Laatste overwegingen bij het uitzoeken van een thema

Mijn eerste pull requests zijn goedgekeurd! Een historische gebeurtenis! Van volslagen insignificant niveau, weliswaar, maar toch. Dit lijkt me een mooie gelegenheid om mijn overwegingen bij het uitzoeken van een thema af te ronden. Of toch in elk geval: voorlopig af te ronden.

Meer overwegingen bij het uitzoeken van een thema

Eerder schreef ik dat ik een nieuw thema voor deze blog wilde uitproberen. Mijn eerste keus bleek niet helemaal wat ik ervan gehoopt had. Gelukkig had ik een tweede keus achter de hand: mini, een thema dat zijn naam eer aandoet en me mijn eerste (bescheiden) stappen in de wereld van open source development deed zetten.

Overwegingen bij het uitzoeken van een thema

Ik ben aan het overwegen het thema van mijn blog te veranderen. Begrijp me niet verkeerd, het huidige thema is prachtig minimalistisch en ik ben er gek op. Maar het is zo… het eerste wat ik tegenkwam. Nu hoeft het eerste wat je tegenkomt niet per se iets slechts te zijn, maar ja, het is wel het eerste wat je tegenkwam. Snap je?

De afgelopen week ben ik dus op zoek gegaan naar een waardige vervanger.

Hoe mijn punthoofd me een punthoofd bezorgde

Op deze blog bevindt zich op dit moment één afbeelding. Het is een afbeelding van mijn hoofd. Best een aardige afbeelding, al zeg ik het zelf (maar misschien ben ik bevooroordeeld).

Ik ben een goed uur uur met die afbeelding bezig geweest. Laat me je vertellen waarom.