d3d8/tests: make sure to use return values (LLVM/Clang)

[Jacek Caban]

On 07/26/11 16:34, Henri Verbeet wrote:
> On 26 July 2011 16:08, Jacek Caban <jacek at codeweavers.com> wrote:
>> If there is no cost of having tests more strict (like code
>> complication), it is a good principle IMO. In this case it's a matter of
>> choosing the right way for testing results, so it should be preferable.
>>
> We're not testing return codes here, so IMO we don't care about them
> beyond detecting failures early. As a general principle though, the
> point has always been to test behaviour that actual applications
> depend on, not finding the most obscure implementation details of
> native. Also, it's not unheard of for some of those details to change
> between Windows versions. If applications don't care, we don't either.

I'm sure apps *do* care about return codes. It's not like we're talking
about an obscure failure corner cases.

>>>  (Not that it matters a lot here anyway, for most of these
>>> D3D_OK is the only possible sucessful return value.)
>> How can you be sure without tests?
>>
> Well, aside from disassembling the entire thing for every single
> Windows version, you can't, even with tests.

Yeah, but with tests I can be much more confident saying so.

But first of all, I don't care about all versions and all corner cases,
I care about the usual case. And that's something tests will show you
easily.

> I mean, native D3D could
> do something obscure like switching all return codes to S_FALSE after
> drawing a green icosahedron, but I think it's somewhat unlikely.

Seriously, I'm not talking about anything like that. We get to choose
between using two things. SUCCEDEED() has no advantages over testing
exact values in this context. Testing the exact value has a small, but
still, advantage. I believe we agree on this. Then if you have a choice,
you choose the one that is slightly better, even if you don't care about
this advantage in this particular case.

Cheers,
    Jacek