Device state management tests

Ivan Gyurdiev ivg231 at gmail.com
Wed Jul 12 10:21:30 CDT 2006


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: d3d9.diff
Type: text/x-patch
Size: 29960 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060712/07301ab7/d3d9-0001.diff


More information about the wine-devel mailing list