[Checkins] SVN: zc.async/trunk/s shorten ftesting helper names; prepare for another internal release.

[Gary Poster]

Log message for revision 87802:
  shorten ftesting helper names; prepare for another internal release.

Changed:
  U   zc.async/trunk/setup.py
  U   zc.async/trunk/src/zc/async/ftesting.py
  U   zc.async/trunk/src/zc/async/ftesting.txt

-=-
Modified: zc.async/trunk/setup.py
===================================================================
--- zc.async/trunk/setup.py	2008-06-26 13:33:55 UTC (rev 87801)
+++ zc.async/trunk/setup.py	2008-06-26 14:21:09 UTC (rev 87802)
@@ -71,7 +71,7 @@
 
 setup(
     name='zc.async',
-    version='1.3a1',
+    version='1.3a2',
     packages=find_packages('src'),
     package_dir={'':'src'},
     zip_safe=False,

Modified: zc.async/trunk/src/zc/async/ftesting.py
===================================================================
--- zc.async/trunk/src/zc/async/ftesting.py	2008-06-26 13:33:55 UTC (rev 87801)
+++ zc.async/trunk/src/zc/async/ftesting.py	2008-06-26 14:21:09 UTC (rev 87802)
@@ -8,7 +8,7 @@
 
 # helper functions convenient for Zope 3 functional tests
 
-def setUpAsync(
+def setUp(
     connection=None,
     queue_installer=zc.async.subscribers.queue_installer,
     dispatcher_installer=zc.async.subscribers.ThreadedDispatcherInstaller(
@@ -21,7 +21,7 @@
     db = connection.db()
     zope.component.provideHandler(agent_installer)
     event = zc.async.interfaces.DatabaseOpened(db)
-    
+
     dispatcher_installer(event)
     dispatcher = zc.async.dispatcher.get()
     _ = transaction.begin()
@@ -31,8 +31,7 @@
     assert dispatcher.activated is not None
 
 
-def tearDownAsync():
+def tearDown():
     dispatcher = zc.async.dispatcher.get()
     dispatcher.reactor.callFromThread(dispatcher.reactor.stop)
     dispatcher.thread.join(3)
-

Modified: zc.async/trunk/src/zc/async/ftesting.txt
===================================================================
--- zc.async/trunk/src/zc/async/ftesting.txt	2008-06-26 13:33:55 UTC (rev 87801)
+++ zc.async/trunk/src/zc/async/ftesting.txt	2008-06-26 14:21:09 UTC (rev 87802)
@@ -20,12 +20,12 @@
 
 But don't have this configuration registered for your ftests. Instead, bypass
 that part of your site's configuration in your ftesting layer, and use the
-``zc.async.ftesting.setUpAsync`` function to set zc.async up in tests when you
-need it, in a footnote of your test or in a similar spot.
+``zc.async.ftesting.setUp`` function to set zc.async up in tests when you need
+it, in a footnote of your test or in a similar spot.
 
 You'll still want the basic adapters registered, as found in zc.async's
 configure.zcml or configure.py files; and maybe the
-zc.async.queue.getDefaultQueue adapter too.  This can be registered in
+zc.async.queue.getDefaultQueue adapter too. This can be registered in
 ftesting.zcml with this snippet::
 
   <include package="zc.async" />
@@ -39,21 +39,21 @@
     >>> import zc.async.queue
     >>> zope.component.provideAdapter(zc.async.queue.getDefaultQueue)
 
-Don't forget to call ``tearDownAsync`` (see below) at the end of your test!
+Don't forget to call ``tearDown`` (see below) at the end of your test!
 
 Here's a usage example.
 
-As mentioned above, ``setUpAsync`` does expect the necessary basic adapters to
+As mentioned above, ``setUp`` does expect the necessary basic adapters to
 already be installed.
 
 Zope 3 ftests generally have a ``getRootObject`` hanging around to give you the
-root object in the Zope application (but not in the ZODB).  Therefore, this
+root object in the Zope application (but not in the ZODB). Therefore, this
 function tries to be helpful, for better and worse, and muck around in the
-locals to find it.  If you want it to leave your locals alone, pass it a
+locals to find it. If you want it to leave your locals alone, pass it a
 database connection.
 
 So, here's some set up.  We create a database and make our stub
-``getRootObject`` function.  
+``getRootObject`` function.
 
     >>> import transaction
     >>> import BTrees
@@ -71,23 +71,23 @@
     ...
 
 Notice we are using a real FileStorage, and not a DemoStorage, as is usually
-used in ftests.  The fact that DemoStorage does not have MVCC can sometimes
-lead standard ftests to raise spurious ReadConflictErrors that will not
-actually occur in production.  The ConflictErrors will generally be retried, so
-your tests should usually pass, even though you might see some "complaints".
+used in ftests. The fact that DemoStorage does not have MVCC can sometimes lead
+standard ftests to raise spurious ReadConflictErrors that will not actually
+occur in production. The ConflictErrors will generally be retried, so your
+tests should usually pass, even though you might see some "complaints".
 
-Now we can call ``setUpAsync`` as if we were in a functional test.
+Now we can call ``setUp`` as if we were in a functional test.
 
     >>> import zc.async.ftesting
-    >>> zc.async.ftesting.setUpAsync()
+    >>> zc.async.ftesting.setUp()
 
-Now the dispatcher is activated and the polls are running.  The function sets
-up a dispatcher that polls much more frequently than usual--every 0.1 seconds
-rather than every 5, so that tests might run faster--but otherwise uses
-typical zc.async default values.
+Now the dispatcher is activated and the polls are running. The function sets up
+a dispatcher that polls much more frequently than usual--every 0.1 seconds
+rather than every 5, so that tests might run faster--but otherwise uses typical
+zc.async default values.
 
-It's worth noting a few tricks that are particularly useful for tests here. 
-We'll also use a couple of them to verify that ``setUpAsync`` did its work.
+It's worth noting a few tricks that are particularly useful for tests here.
+We'll also use a couple of them to verify that ``setUp`` did its work.
 
 ``zc.async.dispatcher.get()`` returns the currently installed dispatcher. This
 can let you check if it is activated and polling and use its simple statistical
@@ -105,10 +105,10 @@
 dispatcher object.
 
 zc.async.testing has a number of helpful functions for testing. ``get_poll`` is
-the most pertinent here: given a dispatcher, it will give you the next poll. 
+the most pertinent here: given a dispatcher, it will give you the next poll.
 This is a good way to make sure that a job you just put in has had a chance to
 be claimed by a dispatcher.  It's also a reasonable way to verify that the
-dispatcher has started.  ``setUpAsync`` already gets the first two polls, so
+dispatcher has started.  ``setUp`` already gets the first two polls, so
 it's definitely all started.
 
     >>> import zc.async.testing
@@ -128,9 +128,9 @@
 
 Once you have finished your tests, make sure to shut down your dispatcher, or
 the testing framework will complain about an unstopped daemon thread.
-zc.async.ftesting.tearDownAsync will do the trick.
+zc.async.ftesting.tearDown will do the trick.
 
-    >>> zc.async.ftesting.tearDownAsync()
+    >>> zc.async.ftesting.tearDown()
     >>> dispatcher.activated
     False