[Bug 794902] qtdemux tests: Add edit list test battery

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=794902

--- Comment #6 from Alicia Boya García <aboya at igalia.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #5)
> Review of attachment 370443 [details] [review]:
> 
> I don't like the Javascript generator, worst it generate a .cpp that get
> included in a C file.

The .cpp extension is just a typo.

> I think all this can be done with macro.

I prefer JS over macros for this because it has features like:

* Conditionals
* Loops
* Lists
* Template strings
* Local variables
* Strings functions (e.g. toUpperCase)
* Procedures (functions that mutate the state of variables)
* Ability to generate newlines in the generated code

All of which C preprocessor, as a language, lacks. If you think you can
replicate my code generator with clean C preprocessor code, you are welcome to
do so; I don't know how to.

Bear in mind this is not only a triple foreach with the variable combinations,
but filtering those that are not supported and those that are known to trigger
expected bugs.

The options here are:

a) Use the JS generator. If you are not working on the tests, you don't have to
do anything because the generated code is already included for this purpose. If
one day you want to disable some tests or add new combinations, you would do so
in the JS file and run it with node. (You could even paste it in the console of
your browser instead if you don't even want to install node).

b) Rewrite the JS generator in another language you may prefer, e.g. Python,
which has worse template strings (they require Py3.6 and cannot be used
recursively or with complex expressions) but would work exactly in the same
way. Still, compared with C macro language it is heaven on Earth and could even
be made into an automatic build target in meson if desired without adding more
dependencies. [In this case, it should be clarified what Python version to
use.]

c) Spend hours researching arcane C macro tricks to bring a monster to life
that somehow performs the same work inside the C compiler. I tried just for
long enough to become aware of how a bad idea that is.

d) No code generation. Easy, just paste the generated code in the test file and
let it be. The result would be big error-prone tables I would not dare to put
my bare hands on. Commenting out a single test in this way is easy, so it may
be tempting; but this way there is no concise way to explain *why* those tests
are disabled or buggy (a known failure may often have several bugs related) or
toggling those conditions when working on the bugs.

e) No tests at all. The easiest. No way to detect regression on time though...

Before going to any of these ways it may be a good idea to ask: is a small,
self-contained JavaScript generator really such a big problem -- especially
considering the tradeoffs we are making?

What option do you prefer?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.