1

My goal is to create a GitHub repo with a module and unit tests that other developers can check out and work on, including running the unit tests. This module does PDF manipulation, so I need to provide some sample PDFs to test, plus paths for inputs & outputs. I put a .ini file and some sample PDFs outside the root of my source code. My unit test's setUp has one hard-coded relative path to the .ini file, which contains all the other inputs needed for the unit tests:

class TestPDF(unittest.TestCase):

    def setUp(self):
        config = configparser.ConfigParser()
        config.read('../../data/tests/test_config.ini')
        self.test_file_path = config['PATHS']['test_file_path']
        # ...create additional config variables...

Those variables, such as self.test_file_path, are then available in all the unit tests in this class. Here is my folder structure:

Repo folder structure

Regarding the config: Is this a good way to deliver the config to my unit tests? This runs just fine, so this is a question of best practices. I assume just about every unit test out there needs to provide some kind of inputs, whether it's file data, URLs, paths, SQL snippets, credentials, tokens, etc., so what is the convention?

Regarding the PDF files: I kept them as small as I can, just for testing (200KB). Again, it technically works fine, but how do repos normally deliver data files like this?

dcafdg
  • 163
  • 2
  • 6
  • I would put `test_config.ini` in `src/pdf_utils`, along side `test.py`. It's not data that's read the code being tested, but by the test suite itself to determine how that code should be called. – chepner May 10 '20 at 20:39
  • @chepner - Thanks, makes sense. I will probably makes 'tests' a sub-module folder at that point to organize it a bit more. If it's going to be mixed in with my code, I might convert it over to a .py file, migrating the config to a dict that can be imported. – dcafdg May 11 '20 at 16:43

0 Answers0