Re: [PATCH 2/7] d3d11/tests: Port test_create_texture2d() from d3d10core.

[Henri Verbeet]

On 10 August 2015 at 01:11, Józef Kucia  wrote:
> configure                    |   3 +-
>  configure.ac                 |   3 +-

It's not a problem to include these, but it's not necessary either.
Alexandre will generate these with tools/make_makefiles before
committing the patch.
> - if (!(device = create_device()))
> - {
> -
>    skip("Failed to create device, skipping tests.\n");
> -
>    return;
> - }
> -

There's nothing necessarily wrong with these tests, but you may want
to consider waiting with submitting them until after they pass. Right
now you're depending on create_device() to fail so the tests are
skipped, but that means that once D3D11CreateDevice() is implemented
you'd need to add todo_wine's and error handling to every test.

[PATCH 2/7] d3d11/tests: Port test_create_texture2d() from d3d10core.

[Józef Kucia]

On Mon, Aug 10, 2015 at 8:48 AM, Henri Verbeet  wrote:
> On 10 August 2015 at 01:11, Józef Kucia  wrote:
> > configure                    |   3 +-
> >  configure.ac                 |   3 +-
>
> It's not a problem to include these, but it's not necessary either.
> Alexandre will generate these with tools/make_makefiles before
> committing the patch.
> > - if (!(device = create_device()))
> > - {
> > -
> >    skip("Failed to create device, skipping tests.\n");
> > -
> >    return;
> > - }
> > -
>
> There's nothing necessarily wrong with these tests, but you may want
> to consider waiting with submitting them until after they pass. Right
> now you're depending on create_device() to fail so the tests are
> skipped, but that means that once D3D11CreateDevice() is implemented
> you'd need to add todo_wine's and error handling to every test.

The implementation of D3D11CreateDevice could be delayed until these tests
pass. ID3D11Device could still be exposed through ID3D10Device. However, it
might be more convenient to include the tests after they pass. I don't mind
resubmitting them later.

How should be approached other tests which potentially influence decision
how to organize D3D10 and D3D11 code? For example, tests which check
implemented interfaces for D3D11Device. Is it preferred to submit them
before implementation?

[PATCH 2/7] d3d11/tests: Port test_create_texture2d() from d3d10core.

[Henri Verbeet]

On 10 August 2015 at 11:01, Józef Kucia  wrote:
> The implementation of D3D11CreateDevice could be delayed until these tests
> pass. ID3D11Device could still be exposed through ID3D10Device. However, it

Yeah, but you'd still basically have the same issue. I.e., when you
make create_device() work in some way, you'd have to adjust all the
tests because e.g. ID3D11Device_CreateTexture2D() returns E_NOTIMPL.
> How should be approached other tests which potentially influence decision
> how to organize D3D10 and D3D11 code? For example, tests which check
> implemented interfaces for D3D11Device. Is it preferred to submit them
> before implementation?

I have no particular preference either way, but in principle it's fine
to submit those before the implementation.