COMP 4004 Lecture Notes - Lecture 1: Test Fixture, Static Variable, Global Variable
26 Oct 2018
School
Department
Course
Professor
5D
• Avoiding Slow Tests – Slow Test Code
o Avoid Waits
▪ Use Humble Object to avoid Asynchronous Test by testing logic directly
o Test Less Code
▪ Reduce Test Overlap
o Set Up Less Fixture
▪ Use a Minimal Fixture
o Set Up Fixture Less Often
▪ Reuse a Shared Fixture
• Shared Test Fixture
o What it is:
▪ Improves test run times by reducing setup overhead.
▪ A “standard” test environment applicable to all tests is built and the tests reuse
the same fixture instance
o Variations:
▪ Fixture is shared between some/all the tests in a single test run
▪ Fixture may be shared across many TestRunners (Global Text Fixture)
o Examples:
▪ Standard Database contents
▪ Standard Set of Directories and Files
▪ Standard set of objects
Bad Smell Alert: Erratic Tests
• Setting Up the Shared Test Fixture
o To share the same fixture instance between tests:
▪ Prebuilt Fixture – Fixture is built ahead of time and reused by many test runs
• Unrepeatable tests
▪ Lazy Setup – First reference causes it to be initialized
• How do you know when to clean up?
• Use only when don’t need to clean up the fixture
▪ SuiteFixture Setup – Use Static variables to hold the fixture. Initialize one before
first test; destroy after last
▪ Setup Decorator – Define a Test Decorator that implements Test. Wrap the test
suite with an instance of the decorator
• Tests that depend on the decorator cannot be run without it
• Pattern: Lazy Setup
o What it is: We use Lazy Initialization to construct the Shared Fixture before the first Test
Method that needs it
o How it works:
▪ Hold reference to fixture in a static or global variable
▪ Use Lazy Initialization of static variable to set up fixture.
▪ Can be done either in the Setup method (Implicit Setup):
▪ Or, in a finder method (Delegated Setup):
• Pattern: SuiteFixtureSetup
o What it is: Test Framework support for sharing test fixtures
o How it works:
▪ All Test Methods in the Testcase Class share the same test fixture.
▪ Like a TestSetupDecorator but only for a single Testcase Class.
▪ TestFixtureSetUp method is called once before first Test Method
▪ SuiteFixtureTearDown Method is called once after last Test Method
o JUnit 4.0+ Specifics:
▪ Indicated by the @beforeClass and @afterClass annotations
• Pattern: SetUp Decorator
o What it is:
▪ We wrap the Test Suite Object with a Behavioral Decorator that sets up and
tears down the fixture
Document Summary
Bad smell alert: erratic tests: setting up the shared test fixture, to share the same fixture instance between tests, prebuilt fixture fixture is built ahead of time and reused by many test runs, unrepeatable tests. Lazy setup first reference causes it to be initialized: how do you know when to clean up, use o(cid:374)l(cid:455) (cid:449)he(cid:374) do(cid:374)"t (cid:374)eed to (cid:272)lean up the fixture, suitefixture setup use static variables to hold the fixture. Initialize one before first test; destroy after last: setup decorator define a test decorator that implements test. If many test runners use the same objects (from global fixture), random results can occur. Interleaving of tests from parallel runners makes determining cause very difficult: non-deterministic test, tests depend on non-deterministic inputs, symptoms, tests pass at some times; fail at other times. Garbage-collected teardown: persistent fresh fixture, fi(cid:454)tu(cid:396)e (cid:374)atu(cid:396)all(cid:455) (cid:862)ha(cid:374)gs a(cid:396)ou(cid:374)d(cid:863) afte(cid:396) test, requires extra effort to ensure it is fresh, persistent fresh fixture, two options, 1.
