Commits

lac committed 757e504

Final check to see that I didn't clobber fixes that happened between
found some, alas. fixed now.

  • Participants
  • Parent commits 0379564

Comments (0)

Files changed (3)

 
 Some of the reasons are historic, others are practical. ``py.test`` used 
 to be part of
-the ``py`` package which provided several developer utitilities,
+the ``py`` package which provided several developer utilities,
 all starting with ``py.<TAB>``, providing nice TAB-completion. If
 you install pycmd with  ``pip install pycmd`` you will get these tools from
 a separate
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 On windows the multiprocess package will instantiate sub processes
-by pickling and thus implicitely re-import a lot of local modules.
+by pickling and thus implicitly re-import a lot of local modules.
 Unfortunately, setuptools-0.6.11 does not ``if __name__=='__main__'``
 protect its generated command line script.  This leads to infinite
 recursion when running a test that instantiates Processes.

File doc/goodpractices.txt

              A good tool to help you automate test runs against multiple
 dependency configurations or Python interpreters is `tox`_,
 independently created by py.test's primary author.  `tox`_
-is also useful for integration with the continous integration
+is also useful for integration with the continuous integration
 server Hudson_.
 
 .. _`virtualenv`: http://pypi.python.org/pypi/virtualenv
 .. _`buildout`: http://www.buildout.org/
 .. _pip: http://pypi.python.org/pypi/pip
 
-Use tox and Continous Integration servers
+Use tox and Continuous Integration servers
 -------------------------------------------------
 
 If you frequently release code to the public you
 may want to look into `tox`_, the virtualenv test automation
 tool and its `pytest support <http://codespeak.net/tox/example/pytest.html>`_.
-The basic idea is to generate a JUnitXML file through the ``--junitxml=PATH`` option and have a continous integration server like Hudson_ pick it up.
+The basic idea is to generate a JUnitXML file through the ``--junitxml=PATH`` option and have a continuous integration server like Hudson_ pick it up.
 
 .. _standalone:
 .. _`genscript method`:

File doc/index.txt

  - advanced :ref:`skip and xfail`
  - generic :ref:`marking and test selection <mark>`
  - can :ref:`distribute tests to multiple CPUs <xdistcpu>` through :ref:`xdist plugin <xdist>`
- - can :ref:`continously re-run failing tests <looponfailing>`
+ - can :ref:`continuously re-run failing tests <looponfailing>`
  - many :ref:`builtin helpers <pytest helpers>`
  - flexible :ref:`Python test discovery`
  - unique :ref:`dependency injection through funcargs <funcargs>`