Hi,
I started writing a test system for d3d state management. Here's what I have in mind (attached). I've converted the constant and recording of missing lights tests to this framework to demonstrate. As a result I've already found two bugs related to lights behavior (see the tests that fail). It's rather complicated, but I think it's more extensive than we we currently have, and may be useful.
Feedback welcome... --------------
How to use to write tests for a particular state: - define a data structure, which will represent the state data. - define initial data sample (this is state the data should be in after the device is created, before any writes take place) - define default data sample (this is the data as it is read later on (may be affected by side effects of writes), and the data that the device is restored to on failure). - define test_in data sample (what to try to set the device to) - define test_out data sample (what windows will actually set the device to - i.e. if you do get afterwards) - define a return buffer to write data to (from get requests) - define a poison data sample to preinitialize the return buffer to - define a get handler - define a set handler - define a print handler (for debugging, when comparison fails) - pack all of the above, along with some other data into a state_test structure add a queue_test function, and run it from test_state_management()
The following tests will be ran [ in that order ], on all states that have a test simultaneously. The "compare" part is a memcmp test on the defined structure. After each test, the data is restored to default data samples.
1. Initial read: - read states - compare to initial data sample
2. Write/Read - write states - read states - compare to test data samples
3. Stateblock Recording - begin stateblock - write states - end stateblock - release stateblock [abort] - compare to default data samples
4. Stateblock Recording + Apply - begin stateblock - write states - end stateblock - apply stateblock - compare to test data samples
5. Stateblock Capture and Reapply - begin stateblock - write states - end stateblock - capture stateblock - compare to default data samples - write states [ again, as poison ] - apply stateblock - compare to default data samples
Planned: - Render target switch test - Render target switch + stateblock interactions
---------------- How it works - a test is represented by an event sequence to be ran on the selected states. Each event is a funciton, and a command state [ which is combined with the function output, to abort on error ]. The test function loops over the events, executes the function, and takes action based on the specified commands: EVENT_CHECK_DEFAULT, EVENT_CHECK_INITIAL, EVENT_CHECK_TESt, EVENT_APPLY_DATA, EVENT_ERROR, EVENT_OK.
The tests above are represented as events sequences, defining new ones isn't too hard.