[PATCH 5/6] quartz/tests/filesource: Add some tests for IBaseFilter_EnumPins().

[Zebediah Figura]

On 27/09/18 03:15, Alexandre Julliard wrote:
> Zebediah Figura <z.figura12 at gmail.com> writes:
> 
>> diff --git a/dlls/quartz/tests/util.h b/dlls/quartz/tests/util.h
>> new file mode 100644
>> index 0000000..fe08c65
>> --- /dev/null
>> +++ b/dlls/quartz/tests/util.h
>> @@ -0,0 +1,4 @@
>> +static const WCHAR avifile[] = {'t','e','s','t','.','a','v','i',0};
>> +static const WCHAR mpegfile[] = {'t','e','s','t','.','m','p','g',0};
>> +
>> +WCHAR *load_resource(const WCHAR *name);
> 
> It's better to avoid dependencies between test files when possible.
> load_resource() is only a few lines and can be duplicated where needed.
> 

The impetus to adding a common header is not so much load_resource() as
to be able to reuse the whole testfilter/testpin infrastructure. It's
useful to be able to connect stock filters to custom filters to test
things like how media types are negotiated, how allocators are
negotiated, how data flows, how EOS/flush/segment notifications are
generated and passed on. Completely avoiding that interdependency would
necessitate duplication of at least 800 lines of code, once per filter
(of which there are at least 9 in quartz), which seems to me less than
desirable, and I figured that as long as code sharing would be desirable
than we might as well share some other utility functions.

I guess one alternative is not to give each source filter its own unit
test, though I'd really rather not do this: it makes more organizational
sense this way, and filters often need subtle differences in how their
test functions are written. test_enum_pins() is a good example: the file
source filter exposes one pin only after IFileSourceFilter_Load() is
called, but the ACM wrapper exposes two pins always, and the AVI
splitter exposes the sink pin always and any number of source pins only
after its input is connected...

I'm still open to using strmbase instead, if this is workable. I
proposed this several months ago to no reply [1], and while I can see
why it's architecturally distasteful, it would eliminate most of the
code sharing or duplication otherwise necessary (plus several hundred
lines of code from filtergraph.c itself).

[1] https://www.winehq.org/pipermail/wine-devel/2018-May/126573.html