There are three levels of setup and teardown available for the unittest modules. These define different kinds of testing scopes: method, class, and module, as follows:

• Test case setUp() and tearDown() methods: These methods ensure that each individual test method within a TestCase class has a proper context. Often, we'll use the setUp() method to create the units being tested and any mock objects that are required. 
• Test case setUpClass() and tearDownClass() methods: These methods perform a one-time setup (and teardown) of all the tests in a TestCase class. These methods bracket the sequence of setUp()-testMethod()-tearDown() for each method. This can be a good place to insert and delete the data required by the test inside a database.
• Module setUpModule() and tearDownModule() functions: These two standalone functions provide us with a one-time setup before all of the TestCase classes in a module. This is a good place to create and destroy a test database as a whole before running a series of TestCase classes.

We rarely need to define all of these setUp() and tearDown() methods. There are several testing scenarios that are going to be part of our design for testability. The essential difference between these scenarios is the degree of integration involved. As noted previously, we have three tiers in our testing hierarchy: isolated unit tests, integration tests, and overall application tests. There are several ways in which these tiers of testing work with the various setup and teardown features including the following:

• Isolated unit, no integration, no dependencies. Some classes or functions have no external dependencies; they don't rely on files, devices, other processes, or other hosts. Other classes have some external resources that can be mocked. When the cost and complexity of the TestCase.setUp() method is small, we can create the necessary objects there. If the mock objects are particularly complex, a class-level TestCase.setUpClass() might be more appropriate to amortize the cost of recreating the mock objects over several test methods.
• Internal integration, some dependencies: Automated integration testing among classes or modules often involves more complex setup situations. We may have a complex setUpClass() or even a module-level setUpModule() to prepare a context for integration testing. When working with the database access layers in Chapter 11, Storing and Retrieving Objects via Shelve, and Chapter 12, Storing and Retrieving Objects via SQLite, we often perform integration testing that includes our class definitions as well as our access layer. This may involve seeding a test database or shelf with appropriate data for the tests.
• External integration: We may perform automated integration testing on larger and more complex pieces of an application. In these cases, we may need to spawn external processes or create databases and seed them with data. In this case, we may have setUpModule() to prepare an empty database for use by all of the TestCase classes in a module. When working with RESTful web services in Chapter 13, Transmitting and Sharing Objects, or testing Programming In The Large (PITL) in Chapter 19, Module and Package Design, this approach could be helpful.

Note that the concept of unit testing does not define what the unit under test is. The unit can be a class, a module, a package, or even an integrated collection of software components. The unit needs to be isolated from its environment to create a focused test.

When designing automated integration tests, it's important to choose the components to be tested. For example, we don't need to test Python libraries; they have their own tests. Similarly, we don't need to test the OS. For example, if our software deletes a file, we don't need to include a check of the filesystem integrity after the file is removed. We don't need to be sure the space was reclaimed. We generally need to trust that libraries and operating systems work correctly. If we're doubtful of the infrastructure, we can run the test suite for the OS or libraries; we don't need to reinvent it. An integration test must focus on testing the code we wrote, not the code we downloaded and installed.