<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: ‘Vice’ Testing</title>
	<atom:link href="http://lostechies.com/seanchambers/2009/04/22/vice-testing/feed/" rel="self" type="application/rss+xml" />
	<link>http://lostechies.com/seanchambers/2009/04/22/vice-testing/</link>
	<description>Just another LosTechies site</description>
	<lastBuildDate>Thu, 13 Sep 2012 07:11:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.2</generator>
	<item>
		<title>By: No More Hacks</title>
		<link>http://lostechies.com/seanchambers/2009/04/22/vice-testing/#comment-298</link>
		<dc:creator>No More Hacks</dc:creator>
		<pubDate>Fri, 24 Apr 2009 09:38:15 +0000</pubDate>
		<guid isPermaLink="false">/blogs/sean_chambers/archive/2009/04/21/vice-testing.aspx#comment-298</guid>
		<description>This is a nice idea. It does require you to own both ends of the code so you can inject the logging &quot;hooks&quot;. If you were working with a closed application that needed testing, you could write an application that sits entirely outside and listens to the log file; then when you get to the &quot;assert&quot; part of your test you see what comes out. In a way this is something like mocking, in a horrible way; rather than asserting on &quot;nouns&quot; (i.e., the internal state of the system under test), you look at what &quot;verbs&quot; the SUT has experienced.

It is also not unlike the test coverage profiling tools; if every log statement in the SUT code has been fired, you&#039;ve probably tested all of it!

It is sort of the converse of pseudo-automated testing like this http://nomorehacks.wordpress.com/2008/12/05/having-trouble-automating-your-tests-then-dont/
</description>
		<content:encoded><![CDATA[<p>This is a nice idea. It does require you to own both ends of the code so you can inject the logging &#8220;hooks&#8221;. If you were working with a closed application that needed testing, you could write an application that sits entirely outside and listens to the log file; then when you get to the &#8220;assert&#8221; part of your test you see what comes out. In a way this is something like mocking, in a horrible way; rather than asserting on &#8220;nouns&#8221; (i.e., the internal state of the system under test), you look at what &#8220;verbs&#8221; the SUT has experienced.</p>
<p>It is also not unlike the test coverage profiling tools; if every log statement in the SUT code has been fired, you&#8217;ve probably tested all of it!</p>
<p>It is sort of the converse of pseudo-automated testing like this <a href="http://nomorehacks.wordpress.com/2008/12/05/having-trouble-automating-your-tests-then-dont/" rel="nofollow">http://nomorehacks.wordpress.com/2008/12/05/having-trouble-automating-your-tests-then-dont/</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
