[Tutor] Integrating TDD into my current project work-flows

[Oscar Benjamin]

On 4 May 2015 at 20:04, WolfRage <wolfrage8765 at gmail.com> wrote:
> I would like some help integrating TDD into my current projects.
> My chosen TDD framework is unittest from the standard library.
> My system details are: Linux Mint 17.1 64-bit, Python 3.4, bzr(for version
> control).
>
> My projects are structured like:
> Project > develop > Project > Project > __main__.py
>                               tests   > __main__.py
> I want to be able to execute my Project from a cwd of:
> Project/develop/Project
> as: Python3 -m Project
> That currently works.

That will only work if there is also a file __init__.py under the
Project/develop/Project/Project directory (alongside the __main__.py
file). Adding a __main__.py file allows the directory to be treated as
a Python script e.g.:

$ python3 Project/develop/Project/Project
$ python3 Project  # Assuming cwd is Project/develop/Project

The -m switch searches for a script as if it were a module using the
module search path. In this case the directory containing the package
Project must be on sys.path and one way to achieve this is to change
directory to the Project/develop/Project directory. Then the Project
folder in this directory is on sys.path.

However a directory is not considered a package unless it contains a
file __init__.py. So if the directory is on sys.path (e.g. in the cwd)
AND their is an __init__.py file then you can do

$ python3 -m Project

and the code in __main__.py will run.

Assuming you have the same setup in the
Project/develop/Project/Project/tests directory (both __init__.py and
__main__.py and Project is on sys.path) then you can run
tests/__main__.py using the module search path as

$ python3 -m Project.tests

Note that this is the same name that you would use to import from the
tests package in interpreter e.g.

>>> from Project.tests import test_stuff

imports from the __init__.py in the tests folder.

> But executing my tests as: Python3 -m tests
> requires that test_Project.py has this hack to import the Project module:
> sys.path.append(os.path.join(os.path.dirname(__file__), '..'))
> do you consider that OK? Is there a better way?
> I call it a hack because every testcase file will have to have this line
> added to it in order to work.

I'm not 100% sure I understand what you're doing but hopefully what
I've written above leads to a better solution.

> I am also using coverage.py and it is good but seems to be testing the
> coverage of my tests, which is not desired, how can I stop this behaviour.
> Or is it really OK.

I don't see any problem with it since it shows how many of your tests
are being run. If you're not running all of your tests then that's a
problem. I don't know how involved your projects are but often large
projects will have tests that run conditionally for example they
only/don't run on certain platforms. In that case it could be useful
each time you run your tests to get a loose idea of how many tests are
being skipped.

Of course it may just be a distraction from the main goal which is
ensuring good coverage of the exported code. You can control which
files coverage tracks and reports the coverage of. I don't know how to
do it the way that you're running coverage (from within Python code).
I've always run coverage from the command line interface using a
configuration file. See here for more on that:

http://nedbatchelder.com/code/coverage/cmd.html#cmd
http://nedbatchelder.com/code/coverage/config.html#config
http://nedbatchelder.com/code/coverage/source.html#source


--
Oscar