Page History

...

Test Data Checked into the Package

We Ideally we do not want to keep large amounts of data under version control. For test data, I think 10 kilobytes or so is Ok, but when it gets larger one should use the external location discussed below. Files that you do check in could go right in the test directory alongisde the test, or you can create new directories for test data. Another standard directory in the SConsTools system is data, which is fine, but it is intended for package data as opposed to testing data. One could also create a subdirectory to the test directory, such as

• test/data  or
• test/fixtures

To hold small amounts of test data.

To construct the correct path to read test data, note that during the nightly build ,the current working directory will be the release directory. Hence a Python unit test might look like

However for data files checked in with the package, the general problem is where to put them, and how to find them at run time. Probably the best practice is to use the data subdirectory. This is intended for application data with the package, so you may want to make a subdirectory under it for testing files. The advantage of the data directory is that it is wired into the release. If you know your package name, you can use an environment variable to find the data directory. For example, if we had

• MyPkg/data/testdata

And put a file in there called mytestfile.txt, then at run time, we could use the environment variable SIT_DATA to find the data subdirectory for the release. The data subdirectory for the release will have soft links to all the data directories for the packages. That is we will have the structure

• unitTestTutorial/MyPkg/data    # our data dir
• unitTestTutorial/data               # release data dir
• unitTestTutorial/data/MyPkg    # soft link to unitTestTutorial/MyPkg/data

And the environment variable SIT_DATA will be a : separated list of directories for data, starting with an absolute path to unitTestTutorial/data. Then one could then write a Python unit test like

    def testMyFile(self):
       import os
       assert 'SIT_DATA' in os.environ, "SIT_DATA not defined. Was sit_setup run?"
       dataPath = os.environ['SIT_DATA'].split(':')[0]
       testDataFilePath = os.path.join(dataPath, 'MyPkg', 'testdata', 'mytestfile.txt')
       assert os.path.exists(testDataFilePath), "test file: %s not found" % testDataFilePath
       self.assertTrue(file(testDataFilePath).read().startswith("my"),
                       msg="Test file=%s doesn't start with my" % testDataFilePath)

    def test_mytest(self): 
        text = file('MyPkg/test/fixtures/myfile.txt','r').read()
        self.assertTrue(text.startswith('file text'))

One thing to note, scons test only runs tests for packages that are part of the working release. It does not run tests for all the packages that are part of the base release. Given this, I think the simplest thing for looking for package data, is to just look in one place, using a path relative to the working release directory like above. This works for the nightly build. It won't work for developers that use the new sit_setup feature that allows them to change directories away from their working release, but I think we should just follow the convention that we run scons test from the working release directory. This is different than how packages work with files in the 'data' subdirectory, where they really should check is the package is part of the working/test release and then look in when writing unit tests is to only use the first path in SIT_DATA which will be for the working release. When working with application data, a package will want to try at least the first two paths in SIT_DATA to check for a MyPkg subdirectory. This allows it to see if it is checked out into the working test release, or just part of the base release.

External Test Data Location

...