<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Unit Testing Roadblocks</title>
	<atom:link href="http://mjtsai.com/blog/2008/08/03/unit-testing-roadblocks/feed/" rel="self" type="application/rss+xml" />
	<link>http://mjtsai.com/blog/2008/08/03/unit-testing-roadblocks/</link>
	<description></description>
	<pubDate>Wed, 07 Jan 2009 21:19:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Daniel Jalkut</title>
		<link>http://mjtsai.com/blog/2008/08/03/unit-testing-roadblocks/#comment-376851</link>
		<dc:creator>Daniel Jalkut</dc:creator>
		<pubDate>Sun, 03 Aug 2008 23:06:21 +0000</pubDate>
		<guid isPermaLink="false">http://mjtsai.com/blog/?p=1765#comment-376851</guid>
		<description>I see - so if you wanted to debug a test you could run py.test, attach, and then invoke the desired test?  Sounds pretty compelling. Thanks for sharing this approach. I like your idea of taking advantage of PyObjC for dev purposes.

Daniel</description>
		<content:encoded><![CDATA[<p>I see - so if you wanted to debug a test you could run py.test, attach, and then invoke the desired test?  Sounds pretty compelling. Thanks for sharing this approach. I like your idea of taking advantage of PyObjC for dev purposes.</p>
<p>Daniel</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael</title>
		<link>http://mjtsai.com/blog/2008/08/03/unit-testing-roadblocks/#comment-376737</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Sun, 03 Aug 2008 20:39:12 +0000</pubDate>
		<guid isPermaLink="false">http://mjtsai.com/blog/?p=1765#comment-376737</guid>
		<description>Daniel: It’s rare that I need to do that, especially since py.test will show a stack trace and the values of various variables and parameters if a test fails. I also use lots of logging, and py.test figures out what each test logged so that it can display it intelligently. If I do need to debug step-by-step, I can attach gdb to the Python process. It may also be possible to start up the tests from within gdb, but I think attaching is simpler (especially since py.test makes it easy to control which tests are run).</description>
		<content:encoded><![CDATA[<p>Daniel: It’s rare that I need to do that, especially since py.test will show a stack trace and the values of various variables and parameters if a test fails. I also use lots of logging, and py.test figures out what each test logged so that it can display it intelligently. If I do need to debug step-by-step, I can attach gdb to the Python process. It may also be possible to start up the tests from within gdb, but I think attaching is simpler (especially since py.test makes it easy to control which tests are run).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Jalkut</title>
		<link>http://mjtsai.com/blog/2008/08/03/unit-testing-roadblocks/#comment-376717</link>
		<dc:creator>Daniel Jalkut</dc:creator>
		<pubDate>Sun, 03 Aug 2008 19:58:51 +0000</pubDate>
		<guid isPermaLink="false">http://mjtsai.com/blog/?p=1765#comment-376717</guid>
		<description>How do you debug when you need to step line by line?  Is there a trick to get gdb to debug your py.test harness?

Daniel</description>
		<content:encoded><![CDATA[<p>How do you debug when you need to step line by line?  Is there a trick to get gdb to debug your py.test harness?</p>
<p>Daniel</p>
]]></content:encoded>
	</item>
</channel>
</rss>
