armi.tests package

General framework-wide testing functions and files.

This package contains some input files that can be used across a wide variety of unit tests in other lower-level subpackages.

armi.tests.getEmptyHexReactor()[source]

Make an empty hex reactor used in some tests.

armi.tests.getEmptyCartesianReactor(pitch=(10.0, 16.0))[source]

Return an empty Cartesian reactor used in some tests.

class armi.tests.Fixture(refDirectory, targets, dependencies, function)[source]

Bases: object

Fixture for presenting a consistent data source for testing.

A Fixture is a class that wraps a function which generates resources needed by one or more tests that doesn’t need to be updated every time tests are run.

Do not use this class directly, instead use the @fixture and @requires_fixture decorators.

armi.tests.fixture(refDirectory=None, targets=None, dependencies=None)[source]

Decorator to run function based on targets and dependencies similar to GNU Make.

Parameters:

  • refDirectory (str) – String reference directory for all targets/dependencies. This makes it possible to simplify file paths. If os.path.abspath(<path>) == <path>, then refDirectory is not used.

  • targets (iterable(str)) – List of targets that the function generates.

  • dependencies (iterable(str)) – List of dependencies that the targets require.

armi.tests.requires_fixture(fixtureFunction)[source]

Decorator to require a fixture to have been completed.

Parameters:

fixtureFunction (function without any parameters) – Fixture function is a function that has been decorated with fixture and is called prior to running the decorated function.

Notes

This cannot be used on classes.

class armi.tests.ArmiTestHelper(methodName='runTest')[source]

Bases: TestCase

Class containing common testing methods shared by many tests.

Create an instance of the class that will use the named test method when executed. Raises a ValueError if the instance does not have a method with the specified name.

compareFilesLineByLine(expectedFilePath, actualFilePath, falseNegList=None, eps=None)[source]

Compare the contents of two files line by line.

Warning

The file located at actualFilePath will be deleted if they do match.

Some tests write text files that should be compared line-by-line with reference files. This method performs the comparison.

This class of test is not ideal but does cover a lot of functionality quickly. To assist in the maintenance burden, the following standards are expected and enforced:

  • The reference file compared against will be called either [name]-ref.[ext] or [name].expected.

  • The file that the test creates will be called [name]-test.[ext] or [name].

Rebaselining the reference files upon large, expected, hand-verified changes is accomodated by rebaselineTextComparisons().

Parameters:

  • expectedFilePath (str) – Path to the reference or expected file

  • actualFilePath (str) – Path to the file that will be compared to expectedFilePath

  • falseNegList (None or Iterable) – Optional argument. If two lines are not equal, then check if any values from falseNegList are in this line. If so, do not fail the test.

  • eps (float, optional) – If provided, try to determine if the only difference between compared lines is in the value of something that can be parsed into a float, and the relative difference between the two floats is below the passed epsilon.

static compareLines(actual: str, expected: str, eps: Optional[float] = None)[source]

Impl of line comparison for compareFilesLineByLine.

if rstripped lines are equal -> Good. Otherwise, split on whitespace and try to parse element pairs as floats. if they are both parsable, compare with relative eps, if provided. A side effect of the epsilon comparison is that differing whitespace between words is treated as irrelevant.

armi.tests.rebaselineTextComparisons(root)[source]

Rebaseline test line-by-line comparison files.

This scans the source tree for failed unit test file comparisons (indicated by the presence of, for example, a -test.inp and a -ref.inp file) and moves the test one to the reference one. The work done can be reviewed/approved in source management.

This is convenient when a large-scope change is made, such as updating the properties of a commonly-used material.

Submodules