TechEd Europe 2012, de vrijdag

Vandaag is het de laatste dag op de TechEd. Net als een achtbaan komt het vandaag met een schok ten einde, de laatste sessies zijn aan de beurt.

Deze vrijdag begin ik met een sessie van Peter Provost. Iedere dag heeft ons team wel van hem mogen genieten, dus het is echt de verslaving aan een dagelijk dosis Provost.

Vandaag gaat het over het testen van ‘untestable code’. Een uitdagig dus.

Dus de voorbeelden van deze week worden nog even aangehaald. Zo is er een unittest die de systeemklok wilt terug zetten. Wat zijn de neveneffecten? En daar is nog de test die een bestand op schijf wilt aanmaken. Hebben we daar rechten voor?

Provost haalt nog even SOLID aan. Dit geldt ook voor unittests.

De oplossing is een combinatie van:
– wrap exteren calls
– Use patterns zoals IOC

Dus Peter demonstreert hoe hij een Fake genereert van bepaalde systeem DLLs. Dit zijn gewoon lege klassen met dezelfde interface als de systeem klassen.

Via delegates/lambda wordt de output van methodes vervangen met eigen code. Refactor dus naar interfaces.

20120629-085517.jpg

In dit voorbeeld injecteert hij een andere implementatie van een afhankelijkheid om de oorspronkelijke code toch te kunnen testen. Hij heeft controle over de dependency.

De Microsoft fakes zijn overigens geen Mocks maat stubs. Bij mocking wordt ook gemeten of bepaalde code wel of niet uitgevoerd is (zijn bepaalde methodes wel/niet aangeroepen). Wellicht was hier nog een oplossing van.

Maar als je niet kunt refactoren, er is een dependency naar bv. een website sessie object, dan heb je een probleem.

Maar Shims kunnen dit oplossen. Hij kan b.v. De DateTime.Now aanroepen vervangen via een ShimDateTime.NowGet = () =>;;;;;;;;;;;;; new DateTime(2000,1,1);

Iedere aanroep naar DateTime.Now wordt naar onze delegate omgebogen, zolang deze aanroep in de bijbehorende ShimContect (een omarming zoals using(ShimContext.Create()){…}) valt.

Peter raad aan de context binnen iedere test te houden en niet enkel aan te maken voor een hele groep aan tests.

Grappig detail: in een ViewModel heeft hij de aanroep naar DateTime.Now ook achter een interface gezet. Deze is dus te injecteren 🙂

In een volgend voorbeeld neemt hij de werking van een DispatchTimer over. Hij override de start methode en hij kan zelf de ticks aftrappen met eigen eventargs. Als hij de werking van een ViewModel test dan zie je dat de ViewModel op onze eigen ticks reageert. Dit is echt een reden om over te stappen naar VS2012 als je MVVM toepast en onderhoudt maar je mag de te testen code niet aanpassen (om interfaces te injecteren). Denk ook eens aan 3e partij componenten…

Dit heeft ook wel Monkey Patching.

Shims is dus erg krachtig maar ook een Code Smell. Gebruik shims alleen voor code die je niet kunt refactoren. De refactor heeft echt de voorkeur. Het is ook trager en je hebt heel veel kennis nodig van het te shimmen systeem.

Het genereren van de Fakes is ook nog te reguleren. In een XML setupbestandje is bv. aan te geven dat je alleen stubs wilt, en geen shims. En het aantal classen kan beperkt worden (bv. alleen DispatchTimer en geen DateTime). Dit scheelt ook tijd bij het aanmaken van de stub (bv. na een update van de originele code).

Zet ook eens Diagnstics op True en Verbosity op Noisy 🙂 Zo krijg je meer info en bestandjes in de obj.debug map. Hier zie je de echt gegenereerde code 😮

Er is ook nog een stub observer. Hiermee is evt. de aanroep naar de stubs en shims te controleren. Dan wordt het toch een soort van mocking.

De volgende sessie ging over MVVM testen voor Phone7. Deze sessie werd gegeven door Andy Wigley.

Ook hij is ooit begonnen met code-behind maar dat wordt al snel heel complex en de MVVM is hierbij de oplossing in de vorm van een goed architectuur.

Deze sessie gaat verder in op MVVM en hoe dit te testen valt.

20120629-032101.jpg

Hij begint met was unittesten eigenlijk is. Het plaatje rond de kosten van bugs die (te) laat gevonden worden wordt even getoond.

Grappig is dat hij een NIET te testen applicatie toont. Het is de tutorial van Microsoft om branfstofkosten te meten. Het is een code-behind applicatie. En een Xaml pagina is niet of nauwelijks te testen. Je krijgt problemen met resources etc.

Met MVVM kies je voor ‘seperation of concerns’.

20120629-033240.jpg

De Xaml roept je viewmodel aan en je viewmodel roept andere interfaces aan, bv. je model. En die ViewModel is wel te testen waarbij je de controle hebt over de injecteren implementaties van de interfaces.

Voor de Xaml is het viewmodel gewoon een instance die als resource beschikbaar is. En de visuele controls lezen en reageren (binden) aan de properties op de Viewcontrol. dit is dus gewoon een list of een string. En knoppen worden aan methodes gekoppeld (Commands). Er is wel 1 vereiste vanuit Xaml perspectief: De Viewmodel moet IPropertychange implementeren. Iedere wijziging op de properties van het ViewModel gaat een seintje geven dat de er specifiek iets gewijzigd is.

Services kunnen geinjecteerd worden als bv. dataservices od sessionservices. Deze services kunnen ook langer dan bepaalde viewmodellen leven en gedeeld worden. En deze zijn eenvoudig te mocken.

Grappig is dat hij naast de command voor de Viewmodel ook nog de buttonclicks gebruikt naar de codebehind. De reden is dat de codebehind voor hem gewoon extra UI logica is. Meer stopt hij er niet in. Echte functionaliteit gaat ALTIJD in de viewmodellen.

Daarna volgde een demonstratie met MVVMLight. Hierbij werd een service buiten de viewmodellen aangemaakt en op afroep geinjecteerd via een IOC oplossing.

20120629-112237.jpg

Na de pause was het tijd voor het echte werk. Wat is er nieuw in WCF4.5?

Dit is inmiddels de 5e WCF versie. De vorige versie was al veel simpelder te configureren. Zo was er vooraf standaard gedrag, je moet alleen je eigen wensen nog configureren.

Deze versie maakt het gebruik nog simpelder. Zo is er de Contract First oplossing. En de WSDL wordt plat. En ASync zit er nu goed in.

In 4.5 hoeft alleen nog maar een service reference toegevoegd te worden en dat genereert al de gewenste configuratie. En in de config wordt via tooltips ook uitgelegd wat de elementen betekenen.

Als je start met een WSDL dan moet je via Svcutil /sc . Dit is prima voor Interop.

En WCF krijgt de aanvraag http://adres?singleWsdl dan worden alles in 1 WSDL gepropt waar vroeger voor iedere namespace aparte bestanden werden gemaakt.

En nu kan WCF ook Task Based Async gebruikt worden. Dit werkt samen met async/await aanroepen.

20120629-131238.jpg

Advertenties