Het schrijven van unit- of integratietesten voelt voor de meeste ontwikkelaars als een noodzakelijk kwaad. Toch weet iedere goede ontwikkelaar dat het testen van software cruciaal is. Als de software niet aangepast kan worden nadat het gereleased is zal dit nog vele malen belangrijker worden. Dit is het geval bij smart contracts, een onaanpasbaar script dat draait op een blockchain.
De ontwikkelomgeving en tools voor het ontwikkelen van smart contracts zijn nog vrij primitief. Ook zijn de error messages die worden teruggegeven vrij generiek of beschrijven niet goed wat er precies fout gaat. Hierdoor stijgt de moeilijkheidsgraad van het oplossen van bugs parallel aan de complexiteit van de smart contracts. Dit komt vooral omdat de tijd die het kost om handmatig te testen erg oploopt: Er spelen steeds meer factoren (condities zoals contracteigenaren, gebruikers of minimale/maximale bedragen) mee, die voor elke handmatige test moeten worden geconfigureerd en kloppen. Wordt er een fout gemaakt of is de bug nog niet opgelost, dan komt er vaak een generieke error terug die niet precies aangeeft waar de fout zit zoals in een traditionele programmeertaal. De handmatige testen duren dus langer, en worden vaker uitgevoerd.
Omdat het testen cruciaal is, steeds langer duurt en een bug catastrofale gevolgen kan hebben is er besloten tijdens het Syncoinproject (onze eigen cryptocurrency waarmee bier besteld kan worden) Test-Driven Development toe te passen.
Test-Driven Development, ook wel TDD genoemd, is een techniek die software ontwikkeling begeleidt door het schrijven van automatische testen. Test-Driven Development is een onderdeel van Extreme Programming. Tijdens het ontwikkelen worden de volgende drie stappen steeds herhaald:
1. Schrijf een test
2. Schrijf de minimale code om de test te laten slagen
3. Refactor het gehele project om een goede structuur te behouden
Door deze stappen steeds uit te voeren zal de code volledig getest zijn en kan een refactor of uitbreiding steeds met vertrouwen worden uitgevoerd.
Terwijl TDD tijdens het ontwikkelen van traditionele software vaak overdreven of traag voelt, komt het de snelheid van smart contract ontwikkeling zelfs ten goede. Het testen van smart contracts kan zo binnen enkele seconden gebeuren, in plaats van soms wel tientallen minuten aan handmatig testen van alle scenario’s. Omdat de testen vooraf worden geschreven wordt er vooraf goed nagedacht vanuit het gebruikersperspectief. Aangezien er ook een test rapport wordt gegenereerd na het tests, waarin de requirements staan vermeld, zijn de testen ook een vorm van documentatie. Het gebruiken van Test-Driven Development is dus tijdens het ontwikkelen van smart contracts het beste van twee werelden.
Afgezien van het feit dat de testen nog steeds geschreven moeten worden, heeft het gebruiken van Test-Driven Development tijdens het ontwikkelen van smart contracts alleen maar voordelen. De code is volledig en sneller getest, geschreven vanuit gebruikersperspectief en er kan met vertrouwen een refactor worden uitgevoerd. Aangezien het schrijven van testen ook programmeren is en TDD een ontwikkelaar veel tijd en frustratie bespaart, verandert het schrijven van unit- en integratietesten van een noodzakelijk kwaad naar een gewaardeerde werkwijze.
