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 <wich...@wiggy.net <mailto:wich...@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@python.org
http://mail.python.org/mailman/listinfo/python-nl
_______________________________________________
Python-nl mailing list
Python-nl@python.org
http://mail.python.org/mailman/listinfo/python-nl
