Developer.Baare.com » unit test http://www.baare.com To succeed in life, you need two things: ignorance and confidence Mon, 06 Feb 2012 16:04:04 +0000 en hourly 1 http://wordpress.org/?v=3.0 Test-Driven Development in Microsoft .NET http://www.baare.com/index.php/2009/06/01/test-driven-development-in-microsoft-net/ http://www.baare.com/index.php/2009/06/01/test-driven-development-in-microsoft-net/#comments Mon, 01 Jun 2009 20:30:20 +0000 admin http://www.baare.com/index.php/2009/06/01/test-driven-development-in-microsoft-net/ Tis ondertussen al even geleden dat ik hem heb uitgelezen, hoog tijd voor mijn beknopte mening dus.

Ik ben onverwaardelijk fan van unit testing en kan mij zeer goed vinden in de meeste extreme programming principes. Test-Driven development zoals begreven in dit boek is voor mij echter een brug te ver. Het lijkt me teveel overhead nog voor je de eerste letter code hebt geschreven. Dikwijls krijgt een project – en zeker de code - pas zijn vaste vorm tijdens het effectief schrijven van de code. Classes kunnen nog herschikt worden, Interface aangepast, etc… Het lijkt me moeilijk om voor zo’n fase al zinnige/nuttige testen te vast te leggen. Het lijkt me efficienter om gaandeweg testen te definieren en te implementeren voor de stukken die al een min of meer vaste vormen hebben.

Test-Driven Development in Microsoft .NET

]]> http://www.baare.com/index.php/2009/06/01/test-driven-development-in-microsoft-net/feed/ 0 Unit testen blijft hard labour http://www.baare.com/index.php/2008/11/18/unit-testen-blijft-hard-labour/ http://www.baare.com/index.php/2008/11/18/unit-testen-blijft-hard-labour/#comments Tue, 18 Nov 2008 18:52:37 +0000 admin http://www.baare.com/index.php/2008/11/18/unit-testen-blijft-hard-labour/ Ondanks het feit dat ik weet dat het me op termijn ( korte zelfs ) tijd gaat sparen, blijft het me moeite kosten om consequent unit tests te schrijven voor al mijn code. Zeker eens de eindmeet in zicht raakt is daar steeds de verleiding om die stap over te slaan en te finishen. Voorlopig houd ik het echter vol. Laten ons hopen dat ik er snel de vruchten van mag plukken…

]]> http://www.baare.com/index.php/2008/11/18/unit-testen-blijft-hard-labour/feed/ 0 Unit Test Web Code Zonder Web Server http://www.baare.com/index.php/2008/10/09/unit-test-web-code-zonder-web-server-httpcontextcurrent/ http://www.baare.com/index.php/2008/10/09/unit-test-web-code-zonder-web-server-httpcontextcurrent/#comments Thu, 09 Oct 2008 18:38:33 +0000 admin http://www.baare.com/index.php/2008/10/09/unit-test-web-code-zonder-web-server-httpcontextcurrent/ Het probleem is als volgt. Je hebt een .Net assembly gemaakt die altijd wordt aangeroepen vanuit een web omgeving. bvb een web site of web service. In deze omgevingen beschik je steeds over dingen zoals HttpContext.Current, MapPath() etc… Maar hoe run je nu unit tests voor deze assembly? In je unit test omgeving is HttpContext.Current uiteraard null. Je kan zelf proberen een HttpContext op te bouwen maar dat valt behoorlijk tegen. HttpContext aanmaken lukt nog, maar eens je probeert dingen als MapPath() aan te roepen begint de miserie…

Om een lang verhaal kort te maken, na een uur of 8 zoeken, prullen en 3 halve oplossingen heb ik dit gevonden : http://haacked.com/archive/2007/06/19/unit-tests-web-code-without-a-web-server-using-httpsimulator.aspx. Een kant en klare oplossing! Het werkt perfect en komt zelfs met zijn eigen batterij unit tests.

Veel plezier ermee

]]> http://www.baare.com/index.php/2008/10/09/unit-test-web-code-zonder-web-server-httpcontextcurrent/feed/ 1