On 4 May 2015 at 20:04, WolfRage <wolfrage8...@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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
