[python-nl] Vervuiling code coverage report

[Gerard Petersen]

Hi all,

Dank voor alle uitleg. Mijn regels test en reguliere code gaan gelijk op 
dus da's een aardig gemiddelde. De tests draaien zonder de viewtests is ook 
een goede (hoe bedoel je blinde vlek mijnerzijds :)

@Wichert:

Ik gebruik de django test client ook omdat er diversen decorators op mijn 
views zitten waar redirects mbt security uit voortkomen die ik hiermee 
fixeer voor toekomstige wijzigingen in mijn code.

Wat ik momenteel inderdaad doe is voor alle paden binnen een view een test 
opzetten. Dat is ook een flinke klus, vandaar het ontstaan van een tekort 
aan overzicht.

Zoals je voorstelt dit eerst met de functies te doen zou je wat minder 
uitputtend over je views heen kunnen. Het is echter wel zo dat ik ook een 
hoop form rendering (en daarmee input validatie) test via het aanroepen van 
views.

Echter heb ik daarvan nog niet scherp hoe ik hier dan mijn voltalligheid 
'meetbaar' kan maken. En ik weet niet of test setups maken om je forms te 
instantieren eenvoudig kan, t.o.v. van het via een view doen.


Mvrgr,

Gerard.

On 09-11-10 22:31, Remco Wendt wrote:
>
>
> 2010/11/9 Wichert Akkerman <wichert at wiggy.net <mailto:wichert at wiggy.net>>
>
>     On 2010-11-9 14:41, Gerard @ Gmail wrote:
>
>         Hi All,
>
>         Ik loop tegen een aspect aan tijdens het schrijven van testcode en ik
>         vroeg me af hoe jullie daar mee om gaan.
>
>         Ik heb een behoorlijk uitgebreide test suite opgezet om mijn Django
>         project in goede banen te lijden (houden).
>
>         Als ik een bepaalde view(method) test waarin functies aangeroepen worden
>         dan zijn die functies volgens mijn coverage report wel gebruikt maar dus
>         niet expliciet getest.
>
>
> Hmmm ik zou je niet blind staren op coverage reports, er zijn genoeg
> manieren om aan te tonen dat die metric niet alles zegt. Wat ik hier wel zie
> is dat je voornamelijk op iets hoger niveau aan het testen bent. Met
> ontwikkelen en het gebruik van testing is het vaak juist fijn om de
> onderdelen van je code die je aanroept in je view functie ook apart te
> testen. Dat zijn dan de units die je unittest, zoals dat dan heet. Je view
> code test je waarschijnlijk middels gebruik van de django test client en dat
> is meer op hoger functioneel niveau.
>
> Ik zou dus zelf altijd bij het ontwikkelen de functies die je aanroept apart
> testen. Dat is dan het stabiele fundament waar je op verder bouwt. Als je
> bezig bent met coverage ga je waarschijnlijk ook kijken naar branching
> binnen je code, dus het aftesten van alle mogelijke paden langs
> if-statements ed. Als je voor een view statement op hoger niveau al die
> combo's moet aftesten die je, in de functies die je aanroept, tegenkomt. Dan
> ben je nogal even bezig. Beter kan je dan die mogelijkheden allemaal
> aftesten in je unit test per unit. En dan als dat allemaal werkt de
> combinatie daarvan aftesten middels zo'n meer functionele test, waarin je
> dan niet tracht uitputtend te zijn.
>
> Remco
> --
> Maykin Media
> Herengracht 416, 1017 BZ Amsterdam
> tel.: +31 (0)20 753 05 23
> mob.: +31 (0)6 187 967 06
> http://www.maykinmedia.nl
>
>
>
> _______________________________________________
> Python-nl mailing list
> Python-nl at python.org
> http://mail.python.org/mailman/listinfo/python-nl