<br><br><div class="gmail_quote">On Tue, Jan 19, 2010 at 9:55 AM, holger krekel <span dir="ltr">&lt;<a href="mailto:holger@merlinux.eu">holger@merlinux.eu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Alfredo,<br>
<div class="im"><br>
On Mon, Jan 18, 2010 at 21:37 -0500, Alfredo Deza wrote:<br>
&gt; I am building some tests for a Python installer that copies some files and<br>
&gt; changes some permissions.<br>
&gt;<br>
&gt; Nothing weird there.<br>
&gt;<br>
&gt; However, in the test class I am starting with a setUp that basically calls<br>
&gt; the installer (so the tests can see if everything is where it should be),<br>
&gt; this is followed by a few assertions and finally a tearDown is called where<br>
&gt; everything gets uninstalled.<br>
&gt;<br>
&gt; When running the tests with nosetests, I see that setUp and tearDown are<br>
&gt; called for *every* method in my test class (e.g. installs =&gt; runs test<br>
&gt; method =&gt; uninstalls ....)<br>
&gt;<br>
</div><div class="im">&gt; Isn&#39;t setUp supposed to be run once at the beginning of the class? or is<br>
&gt; this expected?<br>
&gt;<br>
</div><div class="im">&gt; In case this is expected, is there a way to do it *just once *for all the<br>
&gt; methods?<br>
<br>
</div>The others gave various answers related to unittest and its extensions -<br>
i&#39;d like to add another way using py.test &quot;funcargs&quot;.  The main advantage<br>
is that you can completely decouple test fixture and actual test code, allowing<br>
for more flexibility and ease of doing functional/system testing.<br>
<br></blockquote><div>Would that be specific to py.test ? I am trying to build agnostic tests that can be run with anything<br>and understood in the original way it was written.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Example: you write one or multiple test functions that look like this<br>
(also can be put on a class of course):<br>
<br>
    def test_installer(setupdir):<br>
        # do your tests, setupdir is your fixture state<br>
<br>
This is a test function that runs and works with a &quot;setupdir&quot; function argument.<br>
You define a function argument factory which is invoked to provide<br>
an instance of it:<br>
<br>
    def pytest_funcarg__setupdir(request):<br>
        return request.cached_setup(scope=&quot;session&quot;,<br>
            setup=lambda: MySetupDir(),<br>
            teardown=lambda mysetupdir: mysetupdir.finish()<br>
        )<br>
<br>
The specified &#39;setup&#39; and &#39;teardown&#39; will be called exactly once per<br>
session.  If you don&#39;t run a test that needs the funcarg the factory<br>
function will not be called at all.  In any case, your test functions<br>
can stay completely ignorant from how fixtures are managed.<br>
<br>
You can change scoping by modifying the factory function - e.g.<br>
add a command line option that forces &quot;function&quot; scoping which usually<br>
avoids &quot;cascading failures&quot; and provides better test isolation at the expensve<br>
of longer test run durations.  Useful for a nightly Continous Integration<br>
configuration.<br>
<br>
Lastly, the &#39;request&#39; object is a handle to the particular test<br>
function - it provides access to the test function object, its module,<br>
class object etc. and you can thus easily mark a test to receive a<br>
specially parametrized &quot;setupdir&quot; ...  see <a href="http://tinyurl.com/yfw82l5" target="_blank">http://tinyurl.com/yfw82l5</a><br>
for details.<br>
<br>
cheers,<br>
<font color="#888888">holger<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Alfredo Deza<br><br>