<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" 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><atom:link href="https://thinkinginsideabiggerbox.disqus.com/testing_avoid_setup_and_teardown/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Thu, 03 Jul 2008 04:35:51 -0000</lastBuildDate><item><title>Re: Testing: Avoid setUp and tearDown</title><link>http://johannesbrodwall.com/2008/07/02/testing-avoid-setup-and-teardown/#comment-1799205</link><description>&lt;p&gt;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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christian Rørdam</dc:creator><pubDate>Thu, 03 Jul 2008 04:35:51 -0000</pubDate></item><item><title>Re: Testing: Avoid setUp and tearDown</title><link>http://johannesbrodwall.com/2008/07/02/testing-avoid-setup-and-teardown/#comment-1799204</link><description>&lt;p&gt;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.&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Anders Norås</dc:creator><pubDate>Thu, 03 Jul 2008 03:31:34 -0000</pubDate></item></channel></rss>