Merge lp:~mbp/bzr/fixtures into lp:bzr

[Martin Pool]

This adds the camel's nose of test fixtures as a separate comment.

The specific case I start with is generating unicode strings for use in tests.

See also http://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/#comment-161

[lp:~mbp/bzr/fixtures]

5232. By Martin Pool on 2010-05-14

Change factories from make_ to choose_

[Robert Collins (lifeless)]

Firstly, setUp and tearDown are a great way to separate specification ('I want 4 branches, 3 repositories, 2 servers and a merge proposal in my test') and instantiation ('Dude, where are my branches?'). So I think that setUp/tearDown or a similar pairing are really good to have, because if we do want to be able to have reusable fixtures or declarative fixtures, we won't want to have all their overhead at test suite load time. decorators are another way to achieve that, but it ends up just being function currying, and you don't seem to be taking a decorate-and-insert approach here, either.

Secondly, AIUI you want to head towards a 'what, not how' approach - but this new fixture seems a bit unclear about which it is.

Oh, and are you aware of self.getUniqueString on TestCase? We'll probably want to migrate such things across eventually - it might be worth peeking at its implementation to see how some existing do-things-uniquely code is hanging together. In particular, and I know its trivial, the manual counting for unique numbers seems like a case where you could experiment with how you want things to compose.

All in all I think this can shape up nicely, but I'd like to see a bit more please. Marking work in progress, as after 9 days unreviewed I don't think someone else is going to pop up Right Now :)

If you'd like to land just this bit I'd be ko with that if you add setup and teardown to the contract, and a reference - base class, or standalone do-nothing - that describes the contract and how you hope people will use it.

review: Resubmit

[Martin Pool (mbp)]

On 24 May 2010 07:17, Robert Collins <email address hidden> wrote:
> Review: Resubmit
> Firstly, setUp and tearDown are a great way to separate specification ('I want 4 branches, 3 repositories, 2 servers and a merge proposal in my test') and instantiation ('Dude, where are my branches?'). So I think that setUp/tearDown or a similar pairing are really good to have, because if we do want to be able to have reusable fixtures or declarative fixtures, we won't want to have all their overhead at test suite load time. decorators are another way to achieve that, but it ends up just being function currying, and you don't seem to be taking a decorate-and-insert approach here, either.

Are you saying that the contract of the fixture should have a
setUp/tearDown, or that they should be constructed from the setUp of
the TestCase? If the former then I do agree, as we discussed in
person a while ago. It's useful to separate construction of the
object from its actual preparation. The rationale should be
documented though.

>
> Secondly, AIUI you want to head towards a 'what, not how' approach - but this new fixture seems a bit unclear about which it is.

Agree on both points ;-) I think I'm still trying things on.

>
> Oh, and are you aware of self.getUniqueString on TestCase? We'll probably want to migrate such things across eventually - it might be worth peeking at its implementation to see how some existing do-things-uniquely code is hanging together. In particular, and I know its trivial, the manual counting for unique numbers seems like a case where you could experiment with how you want things to compose.

No, I wasn't aware of that. Anyhow, it is an interesting case -
ideally we want something that scales from that to something very
expensive.

--
Martin <http://launchpad.net/~mbp/>

=== modified file 'NEWS'
--- NEWS	2010-05-14 09:02:35 +0000
+++ NEWS	2010-05-14 15:49:24 +0000
@@ -206,6 +206,9 @@
 Testing
 *******
 
+* Add ``bzrlib.tests.fixtures`` to hold code for setting up objects
+  to test.  (Martin Pool)
+
 * Added ``bzrlib.tests.matchers`` as a place to put matchers, along with
   our first in-tree matcher. See the module docstring for details.
   (Robert Collins)

=== modified file 'bzrlib/tests/__init__.py'
--- bzrlib/tests/__init__.py	2010-05-14 08:10:35 +0000
+++ bzrlib/tests/__init__.py	2010-05-14 15:49:24 +0000
@@ -3700,6 +3700,7 @@
         'bzrlib.tests.test_export',
         'bzrlib.tests.test_extract',
         'bzrlib.tests.test_fetch',
+        'bzrlib.tests.test_fixtures',
         'bzrlib.tests.test_fifo_cache',
         'bzrlib.tests.test_filters',
         'bzrlib.tests.test_ftp_transport',

=== added file 'bzrlib/tests/fixtures.py'
--- bzrlib/tests/fixtures.py	1970-01-01 00:00:00 +0000
+++ bzrlib/tests/fixtures.py	2010-05-14 15:49:24 +0000
@@ -0,0 +1,40 @@
+# Copyright (C) 2005-2010 Canonical Ltd
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+
+
+"""Fixtures that can be used within tests.
+
+Fixtures can be created during a test as a way to separate out creation of
+objects to test.  Fixture objects can hold some state so that different 
+objects created during a test instance can be related.  Normally a fixture
+should live only for the duration of a single test.
+"""
+
+
+class UnicodeFactory(object):
+
+    def __init__(self):
+        self._counter = 0
+
+    def choose_string(self):
+        """Return a new short unicode string."""
+        self._counter += 1
+        # use a mathematical symbol unlikely to be in 8-bit encodings
+        return u"\N{SINE WAVE}%d" % self._counter
+
+    def choose_encoding(self):
+        """Return a new Python string encoding."""
+        return 'cp850'

=== added file 'bzrlib/tests/test_fixtures.py'
--- bzrlib/tests/test_fixtures.py	1970-01-01 00:00:00 +0000
+++ bzrlib/tests/test_fixtures.py	2010-05-14 15:49:24 +0000
@@ -0,0 +1,42 @@
+# Copyright (C) 2005-2010 Canonical Ltd
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+
+"""Tests for test fixtures"""
+
+import codecs
+
+from bzrlib import (
+    tests,
+    )
+from bzrlib.tests import (
+    fixtures,
+    )
+
+
+class TestTestFixtures(tests.TestCase):
+
+    def test_unicode_factory(self):
+        unicode_factory = fixtures.UnicodeFactory()
+        ss1 = unicode_factory.choose_short_string()
+        self.assertIsInstance(ss1,
+            unicode)
+        # default version should return something that's not representable in
+        # ascii
+        self.assertRaises(UnicodeEncodeError,
+            ss1.encode, 'ascii')
+
+        # the encoding chosen by the factory is supported by Python
+        codecs.lookup(unicode_factory.choose_encoding())