<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Thinking inside a bigger box - Latest Comments in Testing: Avoid setUp and tearDown</title><link>http://thinkinginsideabiggerbox.disqus.com/</link><description></description><language>en</language><lastBuildDate>Thu, 03 Jul 2008 08:35:51 -0000</lastBuildDate><item><title>Re: Testing: Avoid setUp and tearDown</title><link>http://www.brodwall.com/johannes/blog/2008/07/02/testing-avoid-setup-and-teardown/#comment-1799205</link><description>Agreed! I think it is important that a test method can be read as a sequence of steps, but the steps can be reusable methods. So I do extract the gory details of actually performing the step, but I usually don't extract a subsequence of steps as a new method. And of course, I try to give the methods as good names as possible, as always.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Thu, 03 Jul 2008 08:35:51 -0000</pubDate></item><item><title>Re: Testing: Avoid setUp and tearDown</title><link>http://www.brodwall.com/johannes/blog/2008/07/02/testing-avoid-setup-and-teardown/#comment-1799204</link><description>Agreed! I often find myself refactoring setup methods to factories called by the individual tests whenever I come across tests that need to do some prep work before they can run. Makes things much easier to grasp when you revisit the test fixtures later.</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anders Norås</dc:creator><pubDate>Thu, 03 Jul 2008 07:31:34 -0000</pubDate></item></channel></rss>