Using Python unittest outside a testing environment

Test frameworks are not just for testing code during development and deployment.

Test frameworks may also be put to good use within your application.

By way of example, consider the possibility of running diagnostics on a live application. Another possibility is checking the validity of an on-the-fly configuration change.

The Python unittest library, part of the standard distribution can easily be incorporated into your live code.

The code example below presents a toy example of a test case, which is then exercised by your application process. The outcome is a test result object which you can query and report on.

import unittest


class TestMe(unittest.TestCase):
    def test_this(self):
        self.assertTrue(False)
    def test_that(self):
        self.assertTrue(True)

loader = unittest.TestLoader()
suite = loader.loadTestsFromTestCase(TestMe)
result = unittest.TestResult()
suite.run(result) # run actually returns result as well as populating it
print result

<unittest .result.testresult="" errors="0" failures="1" run="2">

The variable 'result' is an instance of unittest.TestResult() and has a rich set of attributes and methods as documented here.

Getting started with Sphinx

I really like pdoc as a great lightweight python source code documentation tool.

I like to invoke it:

PYTHONPATH=. pdoc --http --http-host 0.0.0.0 --http-port 8888 --only-pypath

I like to use ReST to format docstrings. Unfortunately I have not been able to get pdoc to display parameter lists as I would hope.

(UPDATE: 20151205: pdoc will honour parameter lists created using Markdown.)

So I switched to using Sphinx. It seems I am not alone in finding the Sphinx documentation hard to use.

After a bit of futzing around, this recipe meets my objective of having nice documentation with the power of Sphinx but the ease of pdoc.

1. Install Sphinx.
2. Invoke sphinx-apidoc -F -o dox
3. cd to the dox directory.
4. Edit conf.py to ensure that sys.path can find the module to be document.
5. make html
6. python3 -m http.server

I hope it works for you.

Python Logging

Just pulling together the best of the web on Python logging:

https://docs.python.org/2/library/logging.html
The standard library documentation.

http://pieces.openpolitics.com/2012/04/python-logging-best-practices/
Insightful and reviewed by Vinay Sajip.

http://victorlin.me/posts/2012/08/26/good-logging-practice-in-python
Helpful tips on which logger levels to use.

http://stackoverflow.com/questions/15727420/using-python-logging-in-multiple-modules
Answer provided by Vinay Sajip.

Plone 3 Setup

One time only

Get python 2.4 something.

$> wget http://peak.telecommunity.com/dist/ez_setup.py
$> python ez_setup.py
$> easy_install ZopeSkel

• PEAK


• ZopeSkel

Do this for each project

paster create -t plone3_buildout 

• Paster

At this point you are asked lots of questions for example about
the path where zope/plone is to be or is already installed
the user name/password for the install, the port number etc.
and some options about debug settings.
This information is used ot build the buildout.cfg file.

After this runs, you have a bootstrap.py file, and src and product directories, and a buildout.cfg file and a var file, all of which are empty.

Then:

cd 
python bootstrap.py

After running bootstrap you have an eggs folder, a develop-eggs folder, a parts folder, and a bin folder. The eggs folder contains some of the PEAK tools:- the setuptools egg and the zc.buildout eggs. The bin folder contains the buildout executable. The parts folder is empty, as is the develop-eggs folder.

• zc.buildout

You are now ready to run the buildout, but at this point it may be worthwhile reviewing the buildout to see if any changes are merited. Possibly none are. Also note, you can run the build out over and over again and it will not eat your Data.fs file, the holy of holies of zope/plone development.