R
Roy Smith
Over the years, I've tried different styles of organizing unit tests.
I used to create a test directory and put all my tests there. I would
maintain a one-to-one correspondence between production source and test
source, i.e. the test code for foo.py would be in test/foo.py.
More recently, I've taken to having foo.py and test_foo.py in the same
directory.
My latest experiment is to just put both the production code and the
test code in the same file, ending with
if __name__ == '__main__':
unittest.main()
So, if I import the file, I get the production code as a module, and if
I run it from the command line, it runs the tests. This makes the file
messier, but it makes the directory structure cleaner and (I think)
makes the whole thing easier to edit.
Any of these work. I'm just curious what organizations other people
have used and what the plusses and minuses ended up being.
I used to create a test directory and put all my tests there. I would
maintain a one-to-one correspondence between production source and test
source, i.e. the test code for foo.py would be in test/foo.py.
More recently, I've taken to having foo.py and test_foo.py in the same
directory.
My latest experiment is to just put both the production code and the
test code in the same file, ending with
if __name__ == '__main__':
unittest.main()
So, if I import the file, I get the production code as a module, and if
I run it from the command line, it runs the tests. This makes the file
messier, but it makes the directory structure cleaner and (I think)
makes the whole thing easier to edit.
Any of these work. I'm just curious what organizations other people
have used and what the plusses and minuses ended up being.