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

Martin A. Brown martin at linux-ip.net
Mon May 4 22:49:44 CEST 2015


Hi there,

> 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.
> 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__), '..'))

Yes, a bit ugly.  Have you tried using nose?  I have used a 
similar project development tree and use nose to run the tests.

Here are a few sample command-lines (I'm on an opensuse-13.2 system 
with Python 3.4 and nose for Python-3.4, which is called 
'nosetests-3.4'):

   nosetests-3.4 -- ./tests/
   nosetests-3.4 --with-coverage -- ./tests/
   nosetests-3.4 --with-coverage --cover-package=Project -- ./tests/

I like nose because it will discover any unittest and doctest 
testing code under the specified files/directories.

> 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.

Agreed, is a hack.

> 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.

That's precisely what coverage is supposed to do--that is it should 
report on how much of the 'code under test' has been exercised by 
the testing code.  So, in fact, it's better than OK--it's the 
primary point!

There are two good things about using coverage.

   #1: You see how much more effort you should invest to get
       substantial testing coverage of the code under test.
       [Though, some code is easy to test and others very difficult.]

   #2: You get a report of the lines in the code under test which are
       NOT yet tested; handy!

Good luck,

-Martin

-- 
Martin A. Brown
http://linux-ip.net/


More information about the Tutor mailing list