[doc/book] spelling fixes in "testing" chapter
authorJulien Cristau <julien.cristau@logilab.fr>
Fri, 11 Jul 2014 13:15:11 +0200
changeset 9880 9adf36ce805e
parent 9879 21278eb03bbf
child 9881 3c2202e7bd31
[doc/book] spelling fixes in "testing" chapter
doc/book/en/devrepo/testing.rst
--- a/doc/book/en/devrepo/testing.rst	Wed Jun 11 16:54:31 2014 +0200
+++ b/doc/book/en/devrepo/testing.rst	Fri Jul 11 13:15:11 2014 +0200
@@ -25,8 +25,8 @@
 http://docs.python.org/library/sqlite3.html) as a backend.
 
 The database is stored in the mycube/test/tmpdb,
-mycube/test/tmpdb-template files. If it does not (yet) exists, it will
-be built automatically when the test suit starts.
+mycube/test/tmpdb-template files. If it does not (yet) exist, it will
+be built automatically when the test suite starts.
 
 .. warning::
 
@@ -34,8 +34,8 @@
   one must delete these two files. Changes concerned only with entity
   or relation type properties (constraints, cardinalities,
   permissions) and generally dealt with using the
-  `sync_schema_props_perms()` fonction of the migration environment
-  need not a database regeneration step.
+  `sync_schema_props_perms()` function of the migration environment do
+  not need a database regeneration step.
 
 .. _hook_test:
 
@@ -85,7 +85,7 @@
 preventing cycles amongst Keyword entities.
 
 The `create_entity` method of connection (or request) objects allows
-to create an entity. You can link this entity to others entities, by
+to create an entity. You can link this entity to other entities, by
 specifying as argument, the relation name, and the entity to link, as
 value. In the above example, the `Classification` entity is linked to
 a `CWEtype` via the relation `classifies`. Conversely, if you are
@@ -95,7 +95,7 @@
 .. note::
 
    the :meth:`commit` method is not called automatically. You have to
-   call it explicitely if needed (notably to test operations). It is a
+   call it explicitly if needed (notably to test operations). It is a
    good practice to regenerate entities with :meth:`entity_from_eid`
    after a commit to avoid request cache effects.
 
@@ -104,7 +104,7 @@
 
 It is possible to have these tests run continuously using `apycot`_.
 
-.. _apycot: http://www.logilab.org/project/apycot
+.. _apycot: http://www.cubicweb.org/project/apycot
 
 .. _securitytest:
 
@@ -115,9 +115,9 @@
 support multiple connections at a time, you must be careful when
 simulating security, changing users.
 
-By default, tests run with a user with admin privileges. This
-user/connection must never be closed. It is accessible through the
-`admin_access` object of the test classes.
+By default, tests run with a user with admin privileges. Connections
+using these credentials are accessible through the `admin_access` object
+of the test classes.
 
 The `repo_cnx()` method returns a connection object that can be used as a
 context manager:
@@ -138,27 +138,27 @@
        req.cnx.commit()
 
 On exit of the context manager, a rollback is issued, which releases
-the connection. Don't forget to issue the `cnx.commit()` calls !
+the connection. Don't forget to issue the `cnx.commit()` calls!
 
 .. warning::
 
-   Do not use the references kept to the entities created with a
-   connection from another !
+   Do not use references kept to the entities created with a
+   connection from another one!
 
 Email notifications tests
 `````````````````````````
 
-When running tests potentially generated e-mails are not really sent
-but is found in the list `MAILBOX` of module
+When running tests, potentially generated e-mails are not really sent
+but are found in the list `MAILBOX` of module
 :mod:`cubicweb.devtools.testlib`.
 
 You can test your notifications by analyzing the contents of this list, which
 contains objects with two attributes:
 
 * `recipients`, the list of recipients
-* `msg`, object email.Message
+* `msg`, email.Message object
 
-Let us look at simple example from the ``blog`` cube.
+Let us look at a simple example from the ``blog`` cube.
 
 .. sourcecode:: python
 
@@ -189,7 +189,7 @@
 `````````````````````
 
 It is easy to write unit tests to test actions which are visible to
-user or to a category of users. Let's take an example in the
+a user or to a category of users. Let's take an example in the
 `conference cube`_.
 
 .. _`conference cube`: http://www.cubicweb.org/project/cubicweb-conference
@@ -199,14 +199,14 @@
 
         def setup_database(self):
             with self.admin_access.repo_cnx() as cnx:
-                self.conf = cnx.create_entity('Conference',
-                                              title=u'my conf',
-                                              url_id=u'conf',
-                                              start_on=date(2010, 1, 27),
-                                              end_on = date(2010, 1, 29),
-                                              call_open=True,
-                                              reverse_is_chair_at=chair,
-                                              reverse_is_reviewer_at=reviewer)
+                self.confeid = cnx.create_entity('Conference',
+                                                 title=u'my conf',
+                                                 url_id=u'conf',
+                                                 start_on=date(2010, 1, 27),
+                                                 end_on = date(2010, 1, 29),
+                                                 call_open=True,
+                                                 reverse_is_chair_at=chair,
+                                                 reverse_is_reviewer_at=reviewer).eid
 
         def test_admin(self):
             with self.admin_access.web_request() as req:
@@ -225,7 +225,7 @@
                                         u'http://testing.fr/cubicweb/add/Track'
                                         u'?__linkto=in_conf%%3A%(conf)s%%3Asubject&'
                                         u'__redirectpath=conference%%2Fconf&'
-                                        u'__redirectvid=' % {'conf': self.conf.eid}),
+                                        u'__redirectvid=' % {'conf': self.confeid}),
                                        ])
 
 You just have to execute a rql query corresponding to the view you want to test,
@@ -234,7 +234,7 @@
 that must be visible in the interface. This is a list of tuples. The first
 element is the action's `__regid__`, the second the action's class.
 
-To test actions in submenu, you just have to test the result of
+To test actions in a submenu, you just have to test the result of
 :meth:`~cubicweb.devtools.testlib.CubicWebTC.action_submenu` method. The last
 parameter of the method is the action's category. The result is a list of
 tuples. The first element is the action's title, and the second element the
@@ -277,14 +277,14 @@
 Cache heavy database setup
 -------------------------------
 
-Some tests suite require a complex setup of the database that takes
-seconds (or event minutes) to complete. Doing the whole setup for all
-individual tests make the whole run very slow. The ``CubicWebTC``
-class offer a simple way to prepare specific database once for
+Some test suites require a complex setup of the database that takes
+seconds (or even minutes) to complete. Doing the whole setup for each
+individual test makes the whole run very slow. The ``CubicWebTC``
+class offer a simple way to prepare a specific database once for
 multiple tests. The `test_db_id` class attribute of your
-``CubicWebTC`` must be set a unique identifier and the
-:meth:`pre_setup_database` class method build the cached content. As
-the :meth:`pre_setup_database` method is not garantee to be called
+``CubicWebTC`` subclass must be set to a unique identifier and the
+:meth:`pre_setup_database` class method must build the cached content. As
+the :meth:`pre_setup_database` method is not garanteed to be called
 every time a test method is run, you must not set any class attribute
 to be used during test *there*. Databases for each `test_db_id` are
 automatically created if not already in cache. Clearing the cache is
@@ -294,8 +294,9 @@
 .. warning::
 
   Take care to always have the same :meth:`pre_setup_database`
-  function for all calls with a given `test_db_id` otherwise your test
-  will have unpredictable results depending on the first encountered one.
+  function for all classes with a given `test_db_id` otherwise your
+  tests will have unpredictable results depending on the first
+  encountered one.
 
 
 Testing on a real-life database
@@ -341,7 +342,7 @@
 The format is:
 
 * possibly several empy lines or lines starting with ``#`` (comment lines)
-* one line containing a coma separated list of cube names.
+* one line containing a comma-separated list of cube names.
 
 It is also possible to add a ``schema.py`` file in
 ``mycube/test/data``, which will be used by the testing framework,
@@ -352,12 +353,12 @@
 --------------------
 
 CubicWeb provides some literate programming capabilities. The :ref:`cubicweb-ctl`
-`shell` command accepts differents format files. If your file ends with `.txt`
-or `.rst`, the file will be parsed by :mod:`doctest.testfile` with CubicWeb
+`shell` command accepts different file formats. If your file ends with `.txt`
+or `.rst`, the file will be parsed by :mod:`doctest.testfile` with CubicWeb's
 :ref:`migration` API enabled in it.
 
-Create a `scenario.txt` file into `test/` directory and fill with some content.
-Please refer the :mod:`doctest.testfile` `documentation`_.
+Create a `scenario.txt` file in the `test/` directory and fill with some content.
+Refer to the :mod:`doctest.testfile` `documentation`_.
 
 .. _documentation: http://docs.python.org/library/doctest.html
 
@@ -394,7 +395,7 @@
 
 Passing paramaters
 ``````````````````
-Using extra arguments to parametrize your scenario is possible by prepend them
+Using extra arguments to parametrize your scenario is possible by prepending them
 by double dashes.
 
 Please refer to the `cubicweb-ctl shell --help` usage.
@@ -421,7 +422,7 @@
   discover them automatically)
 * launch `pytest unittest_foo.py` to execute one test file
 * launch `pytest unittest_foo.py bar` to execute all test methods and
-  all test cases whose name contain `bar`
+  all test cases whose name contains `bar`
 
 Additionally, the `-x` option tells pytest to exit at the first error
 or failure. The `-i` option tells pytest to drop into pdb whenever an
@@ -450,7 +451,6 @@
 What you need to know about request and session
 -----------------------------------------------
 
-
 .. image:: ../images/request_session.png
 
 First, remember to think that some code run on a client side, some
@@ -466,12 +466,12 @@
 
 .. note::
 
-   These distinction are going to disappear in cubicweb 3.21 (if not
+   These distinctions are going to disappear in cubicweb 3.21 (if not
    before).
 
 A repoapi connection is tied to a session in the repository. The connection and
-request objects are unaccessible from repository code / the session object is
-unaccessible from client code (theoretically at least).
+request objects are inaccessible from repository code / the session object is
+inaccessible from client code (theoretically at least).
 
 The web interface provides a request class.  That `request` object provides
 access to all cubicweb resources, eg:
@@ -487,7 +487,7 @@
 
 
 A `session` provides an api similar to a request regarding RQL execution and
-access to global resources (registry and all), but also have the following
+access to global resources (registry and all), but also has the following
 responsibilities:
 
 * handle transaction data, that will live during the time of a single
@@ -537,12 +537,12 @@
 
 3. the query is executed (through the repository connection)
 
-4. this query may trigger hooks. Hooks and operation may execute some rql queries
+4. this query may trigger hooks. Hooks and operations may execute some rql queries
    through `cnx.execute`.
 
 5. the repository gets the result of the query in 1. If it was a RQL read query,
    the database connection is released. If it was a write query, the connection
-   is then tied to the session until the transaction is commited or rollbacked.
+   is then tied to the session until the transaction is commited or rolled back.
 
 6. results are sent back to the client
 
@@ -554,6 +554,6 @@
 * however, take care when writing tests: you are usually faking /
   testing both the server and the client side, so you have to decide
   when to use RepoAccess.client_cnx or RepoAccess.repo_cnx. Ask
-  yourself "where the code I want to test will be running, client or
-  repository side ?". The response is usually: use a repo (since the
+  yourself "where will the code I want to test be running, client or
+  repository side?". The response is usually: use a repo (since the
   "client connection" concept is going away in a couple of releases).