Deze blogpost bestaat uit 2 delen, om niet in een keer te diep op de stof in te gaan. In het eerste deel zal ik meer uit de doeken doen waar het nou eigenlijk om gaat en geef ik concrete voorbeelden van metrieken en in het tweede en laatste deel ga ik deze op code loslaten om het praktische gebruik ervan te demonstreren.
In het eerste deel van dit blog artikel heb ik het gehad over hoe mock objecten zijn te maken met EasyMock, jmockit, en hoe er zelf een framework voor te maken is. In dit tweede deel laat ik wat zien van hoe deze frameworks technisch zijn geimplementeerd.
Lees verder
In mijn eerste blog artikel (ooit!) wil ik het graag hebben over het mocken van objecten in Java unittests.
Het is gesplitst in twee delen. In dit eerste deel zal ik kort wat highlights beschrijven van 2 Java mocking frameworks, iets vertellen over een eigen frameworkje wat ik voor dit artikel heb gemaakt, en het een en ander ook vergelijken met mocken in Groovy. In een later volgend deel kijk ik kort naar de implementatie-wijzen van de frameworks.
Lees verder
Binnen de testwereld van Nederland is TMap een veelgebruikte methodiek om te testen. TMap heeft als doel om het testen gestructureerder te laten plaatsvinden. Hiervoor biedt het middelen om het testen een plaats te geven in het software ontwikkel proces en daarnaast middelen om het testen op zich te verbeteren. Maar wat heb je nou aan TMap als je niet test? En kan TMap ook problemen geven? Om deze vragen te beantwoorden, zal ik twee basisprincipes van TMap bespreken, waar ik ook het effect voor developers zal noemen.
Een tijd geleden was ik Selenium al eens tegen gekomen, het leek een interessant product maar ik heb er nooit echt veel tijd aan geschonken. Niet zo gek lang geleden kwam Selenium weer onder mijn ogen en besloot ik er dit keer wat meer tijd in te steken. In dit blogartikel deel ik mijn ervaringen.
Bij sommige projecten wordt er serieus aandacht besteed aan kwaliteitscontroles. Elke class die ingecheckt wordt moet voorzien zijn van testcases die 85% van de code raken en 100% van de branches binnen de code. Ook mag CheckStyle, een tool die code beoordeeld of deze aan de standaarden voldoet, geen commentaar meer hebben en wordt de code ook nog door een reviewer bekeken, zodat de unittests niet alleen geschreven worden om de coverage te halen, maar ook daadwerkelijk controles uitvoeren. Toch kunnen er nog verdachte stukken code doorheen slippen. In een verloren uurtje heb ik FindBugs maar eens los gelaten op de code. De leukste bug is bewaard voor het einde van dit artikel.
Lees verder
Als een groot aantal ontwikkelaars aan één ding een broertje dood hebben dan is het wel aan testen. Hoe krijg je die zelfde ontwikkelaar dan aan test-driven development? Simpel, je vermijdt te allen tijde het woord test. Dus test-driven development wordt behaviour-driven development en je vervangt het unit-test framework JUnit door JBehave.
Lees verder
En half jaar geleden woonde ik een presentatie over RSPec van Aslak Hellesøy bij op RubyEnRails 2007. RSpec is een framework dat de ontwikkelaar een DSL aanbiedt voor het beschrijven van verwacht gedrag van een stuk code.
Het schrijven van specificaties die gebruikt worden om te bepalen of code doet wat men ervan verwacht, wordt ook wel “Behavior Driven Development” (BDD) genoemd. Persoonlijk vind ik het een erg intuïtieve manier voor het schrijven van tests. Tevens is het zo dat de rapportages die door bijvoorbeeld RSpec worden gegenereerd ook door een niet-techneut gelezen kunnen worden. Hierdoor wordt hetgeen getest wordt inzichtelijker.
Lees verder