Archives:
- November 2011
- Avgust 2011
- Junij 2011
- Maj 2011
- April 2011
- Januar 2011
- December 2010
- November 2010
- Avgust 2010
- Julij 2010
- Junij 2010
- Maj 2010
- Februar 2010
- Januar 2010
- December 2009
- November 2009
- September 2009
- Julij 2009
- Junij 2009
- April 2009
- Marec 2009
- Februar 2009
- November 2008
- Oktober 2008
- September 2008
- Avgust 2008
- Julij 2008
- Junij 2008
- Maj 2008
- April 2008
- Marec 2008
- Januar 2008
- December 2007
- November 2007
- Oktober 2007
- September 2007
- Avgust 2007
- Julij 2007
- Junij 2007
- Maj 2007
- April 2007
- Marec 2007
- Februar 2007
- Januar 2007
- December 2006
- November 2006
- Oktober 2006
- September 2006
- Avgust 2006
- Julij 2006
- Junij 2006
- Maj 2006
- April 2006
- Marec 2006
- Februar 2006
- Januar 2006
- December 2005
- November 2005
- Oktober 2005
- September 2005
- Avgust 2005
- Julij 2005
Meta:
Categories:
- blunt-hate
- comp
- debian
- django
- dogbert
- dovhcajt
- faks
- kiberpipa
- kitchen sink
- kultura
- linux
- ljubljana
- mediji
- opendata
- pootle
- python
- slovenija
- zanimivosti
Recent Posts:
- Prosti podatki za zabavo: 22. Liffe
- Kako pravilno uporabljati Supervizor
- Trgovanje z Burmo
- Avtoprevozniški hlapci
- Ne tolerirajte, da vam pijanci narekujejo dejanja
- Kolesarska zmaga: Bicike(LJ) in Android aplikacija
- Zakaj mora vsak operater kakršnega koli omrežja javno objaviti pregled nad stanjem omrežja
- 598
- Naj poslancem krava crkne
- Malo delo: da ali ne?
Blogroll:
Django and coverage.py, the DRY way
Posted on September 25th, 2009 in django, python |
So you want to use Ned Batchelder’s coverage.py and don’t want to install another Django app, don’t want to patch Django files or you just can’t wait for bug #4501 to be resolved.
Me too.
So I took a couple of minutes and put together this very very DRY-ish djangocoverage module, which binds together coverage.py with Django. It is based on a bit aged Siddharta Govindaraj’s snippet. Initially I intended to monkeypatch Django from manage.py, but finding out about TEST_RUNNER setting, I made a saner decision and provided a test runner.
import coverage def coverage_decorator(func, omit_prefixes=None): "Decorator for Django's built in test runner" def _inner_coverage(*args, **kwargs): from django.conf import settings c = coverage.coverage() c.erase() c.start() retval = func(*args, **kwargs) c.stop() coverage_dir = getattr(settings, 'COVERAGE_DIR', './coverage_results') c.html_report(directory=coverage_dir, omit_prefixes=omit_prefixes) return retval return _inner_coverage def coverage_test_runner(*args, **kwargs): "Test runner you can put in your application's settings file" from django.test import simple return coverage_decorator(simple.run_tests)(*args, **kwargs)
What you want to do is put djangocoverage.py somewhere where Python can find it and put “TEST_RUNNER=’djangocoverage.coverage_test_runner’” line into your settings.py.
Then, running tests is the same as it was. If you’re already using custom test runner, then you can easily integrate coverage.py using decorator, if you haven’t yet been using coverage.py. HTML report is written out in ./coverage_report, and you can also adjust that via COVERAGE_DIR setting. Hope you find it helpful.



![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=ccb793bd-e725-4120-ae10-923c6c083b98)