On 27/09/18 03:15, Alexandre Julliard wrote:
Zebediah Figura z.figura12@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