pedorus schreef op zondag 03 maart 2013 @ 23:57:
[...]
Ik denk het niet. Maar dat hangt compleet af van het project. Als je een project hebt met veel middelmatige of slechte programmeurs die moeten samenwerken, is het waarschijnlijk goed om unit tests te maken.
Slechte programmeurs schrijven slechte unit tests
Maar als je een hoop verloop hebt van redelijke tot goede programmeurs is het wel fijn dat die gewoon meteen aan de slag kunnen en er van uit kunnen gaan dat alle unit tests die geschreven zijn allerlei dingen die je niet kunt voorzien als je geen intieme kennis hebt van het project opvangen.
Wat erger is dat een middelmatige programmeur een heel belangrijk programma schrijft op een gegeven moment onvervangbaar wordt en bij iedere ranzige change of bugfix die doorgevoerd wordt de code weer een stukje verder alleen nog maar te ontwarren is door die persoon.
Ik heb bij een toko gewerkt waar zeg maar bij tegenslag mensen er uit gewerkt werden (dat begon dan met een officiele waarschuwing bij om 09:05 binnen komen) die vervangbaar waren. Kortom, de mensen die mensen wiens projecten nog over te nemen waren door andere programmeurs, want geschreven in nette code.
pedorus schreef op zondag 03 maart 2013 @ 23:57:
[...]
Echter, unit tests kosten gewoon tijd. Tijd die ik in de meeste gevallen niet terug kan verdienen. Verhaaltjes anders: Bij [zeer bekend groot IT bedrijf] was een project waar 1 iemand unit tests ging schrijven. In minder tijd programmeerde iemand anders iets dat werkte, en werd de persoon van de unit tests de laan uitgestuurd.
Dan ben je ook een stuk hout als je een beetje in het wilde weg unit tests gaat lopen schrijven waar niemand om gevraagd heeft en die ook niet afgedwongen worden in je software straat. Als ik ergens werk waar het geen gemeengoed is schrijf ik ze niet, tenzij ze het mij makkelijker maken om mijn werk te doen.
pedorus schreef op zondag 03 maart 2013 @ 23:57:
[...]
Bij [belangrijke internationale transactiebank] werkt iemand die als enige unit tests schrijft. Hij merkt toch dat hij een stuk trager is met opleveren, hoewel unit tests in zijn geval op zich zinnig zouden kunnen zijn. De code coverage is 1 procent, toch gaan er miljarden over heen.

Maar wordt die code ook iedere week opnieuw gereleased of gaat dat in grote stappen met bergen QA?
pedorus schreef op zondag 03 maart 2013 @ 23:57:
[...]
Bij sommige projecten moet het gedrag van de software zeer regelmatig aangepast worden. Dat zou dan betekenen dat ook de unit tests steeds herschreven moeten worden. Lijkt me niet handig.
Het is wel handig dat de unit tests in de delen waar je niks aanpast ineens meldingen gaan geven op het moment dat een bepaalde grote change meer impact heeft dan je in kunt schatten, bijvoorbeeld omdat iemand eerder om een bug heen heeft lopen programmeren.
pedorus schreef op zondag 03 maart 2013 @ 23:57:
[...]
Het is handiger om alleen tests te maken voor situaties waar dit daadwerkelijk nuttig is. Veel unit tests worden in mijn beleving toch vooral geschreven om de 'code coverage' omhoog te krijgen, in plaats van dat daadwerkelijke interessante situaties worden getest. Vaak wordt het pas interessant op hogere niveaus.
Normaliter schrijf je unit tests om business features of changes te bewijzen (bij drie producten krijg je de vierde gratis tussen mei en december) of om bepaalde bugreports te herhalen en daarna op te lossen (als ik meer dan int32 records heb moet ik geen error meer krijgen). Code coverage daar doe ik persoonlijk helemaal niks mee, alle code en tests worden gereviewd. Wel heb je nadat je alles in unit tests gevat hebt meer documentatie in je code zitten, namelijk hoe hij gebruikt wordt. En ga je je hele rule engine refactoren heb je in ieder geval meteen een set regels waaraan je code moet voldoen plus een berg tests. Dus eigenlijk wordt een grotere refactor juist makkelijker en alle gebroken tests duiden je waar de belangrijke punten zitten die opnieuw gecheckt moeten worden.
pedorus schreef op zondag 03 maart 2013 @ 23:57:
[...]
Het blijkt dat ernstige problemen (systeem uitval, raket stort neer, enz.) bijna altijd komen door rare events. Denk hierbij aan een schrikkelseconde, tijdelijke uitval van hardware, dat soort dingen. Het geval wil dat unit tests dat soort situaties zelden testen.
Maar nadat je een schrikkelseconde probleem hebt gehad heb je een schrikkelseconde bugreport die je moet oplossen dan bouw je daar een test voor en wordt hij over vijf jaar nog steeds getest.
Is ook zo. Ik denk dat blind dogma's toepassen gewoon nooit een goed idee is. Ik heb in ieder geval verschillende situaties met en zonder unit tests gezien in gelijksoortige projecten en ik heb gezien welke wel en niet goed werkten en wanneer je tegen de limieten aanloopt van een project zonder tests wat met een slecht testbare architectuur gebouwd is. Ik hoor ze bij Facebook vanaf hier vloeken in ieder geval

maar ze zijn wel juist zo groot geworden doordat ze gewoon snel features konden releasen zonder in een stijf harnas te zitten.
Ik probeer in ieder geval altijd goed testbare code te schrijven, maar ik schrijf lang niet altijd tests. Maar mocht het een keer moeten, hoef ik in ieder geval niet meer mijn hele project te refactoren.