<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Thanks for all the responses so far!<div><br></div><div>For completeness heres the project link for venusian decorators:</div><div><br></div><div><a href="http://pypi.python.org/pypi/venusian">http://pypi.python.org/pypi/venusian</a></div><div><br></div><div>Venusian style decorators add attributes to function/methods/classes including a callback which is invoked by a later 'scan' stage -- the pyramid framework uses this system to mark function/methods as web request handlers in a nice/flexible fashion. But Tres's links have convinced me that there's nothing inherently 'magic' about this process which would lead to coverage.py missing function/method calls.<br><div><br></div><div>I tried running coverage conventionally like so:</div><div><br></div><div>coverage run /path/to/my/pythonenv/bin/pserve development.ini</div><div><br></div><div>pserve is a script that's part of the pyramid web framework. The high level view of what it does is:</div><div><br></div><div>1. create the wsgi object representing a web application</div><div>2. setup a wsgi server </div><div>3. pass the application object to the server for serving. </div><div><br></div><div>After starting the server thusly, then invoking my test suite, I kill the serve process and run:</div><div><br></div><div>coverage html</div><div><br></div><div>to generate the html report. The report is essentially the same as the one generated by the api calls and shows that none of my application's view methods are being called...</div><div><br></div><div>I had mentioned earlier that I was using the single-threaded waitress http server -- however that's not true -- waitress is a multi-threaded server -- I'm using it in its default configuration. There's a little bit of magic with threads happening largely behind the scenes within the framework/http server -- my functions/methods will all be called in a thread from a thread worker pool -- would it be expected for coverage to fail to trace methods called in a thread other than the MainThread?</div><div><br></div><div><div><div>On Aug 24, 2012, at 7:48 AM, Tres Seaver <<a href="mailto:tseaver@palladion.com">tseaver@palladion.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>On 08/24/2012 10:35 AM, Tres Seaver wrote:<br><blockquote type="cite">On 08/23/2012 08:34 PM, Ben Cohen wrote:<br><br><blockquote type="cite">The most obvious shared feature of the functions/methods that<br>report no coverage is the use of a venusian callback method<br>decorator -- this decorator marks functions/methods with declarative<br>attributes, subsequently modules are scanned for methods with those<br>attributes and then ingested by the pyramid web framework's<br>web-publishing machinery.<br></blockquote><br><blockquote type="cite">Is there some magic happening within the pyramid framework that <br>causes coverage to fail to register when these methods are called?<br>Is anybody using coverage and pyramid together without issue …? I<br>didn't expect so fundamental an issue with the two as the pyramid <br>documentation has a chapter describing the use of coverage in unit <br>tests …<br></blockquote><br>Pyramid itself runs tests with the coverage package without issues<br>(run via 'setup.py nosetests --with-xunit --with-xcoverage' -- see the<br>'cover' environment in its tox.ini). We use it routinely for apps<br>built on Pyramid as well. The venusian decorator does not do anything<br>to interfere with coverage: the attributes it adds to the decorated <br>function are used to populate Pyramid's registry during the later<br>"scan" phase.<br></blockquote><br>Pyramid's Jenkins:<br><br> <a href="http://jenkins.pylonsproject.org/job/pyramid/">http://jenkins.pylonsproject.org/job/pyramid/</a><br><br>and the instance for SubstanceD, an app written on top of Pyramide:<br><br> <a href="http://jenkins.pylonsproject.org/job/substanced/">http://jenkins.pylonsproject.org/job/substanced/</a><br><br><br>Tres.<br>- -- <br>===================================================================<br>Tres Seaver +1 540-429-0999 <a href="mailto:tseaver@palladion.com">tseaver@palladion.com</a><br>Palladion Software "Excellence by Design" <a href="http://palladion.com">http://palladion.com</a><br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.11 (GNU/Linux)<br>Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/">http://enigmail.mozdev.org/</a><br><br>iEYEARECAAYFAlA3lB8ACgkQ+gerLs4ltQ4tmQCgx9jQjZPXJJlme1ZrNqm46rMb<br>KEIAn2SE/Cz43KS/f+61XVb6HcqtiHzK<br>=vlKO<br>-----END PGP SIGNATURE-----<br><br><br>_______________________________________________<br>testing-in-python mailing list<br><a href="mailto:testing-in-python@lists.idyll.org">testing-in-python@lists.idyll.org</a><br>http://lists.idyll.org/listinfo/testing-in-python<br></blockquote></div><br></div></div></body></html>