[Bug 751916] Add GstHarness test framework

[GStreamer (GNOME Bugzilla)]

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

--- Comment #5 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
> >  - does struct _GstHarness need to be public? Should be made private IMHO
> If this was a "normal" implementation, I would absolutely agree, however,
> since this is code meant for testing, and testing only, I often find it very
> useful to be able to access the internals with the higher goal of writing
> better tests. The best example of this is actually the sub-harnesses, where
> we often do what you suggest further down, in nesting the harnesses, and
> being able to access them. Very common pattern in many of our tests is
> adding a launch-line as a src-harness (gst_harness_add_src_parse) and then
> use gst_harness_find_element on h->src_harness in order to access an element
> inside the src_harness

I get that, but it means it's hard to change implementation details later. I
guess you have more confidence than me in the details given you've been using
this a bit longer..

Are you mainly accessing the sub-harnesses, or other things too?

I was actually wondering if the sub-harness creation function should perhaps
return a pointer to the sub-harness.


> >  - confusing terminology: (basically caused by leaking implementation
> > details into the API?):
> >     - gst_harness_set_src_caps() = input caps, and _set_sink_caps() = output
> > caps
> >     - gst_harness_add_src() etc. [wonder if "input" would generally be
> > nicer?]
> >     - e.g. "Pulls a #GstBuffer from the #GAsyncQueue on the #GstHarness
> > sinkpad"
> So this is not confusing to me, having used this now for 3 years, but I do
> see your point. The harness has a srcpad and sinkpad, and being able to
> define their caps is important. Also with the harnesses, you are effectively
> adding an "alternative" src-pad for your harness with a src-harness, making
> the naming consistent with GStreamer uses for src and sink. 

Yeah, I get that of course. And I'm fine with it, but I think these details
need to be documented/described somewhere then (or maybe they are and I missed
it).


> >  - example in the docs section at the beginning: not even a _play() required?
> >    what is _play for then?
> RTFM :) I think I documented that quite well in the docstring for
> gst_harness_play? 

Fair enough - by "src elements" you mean source elements in general, or src
sub-harnesses?

> >  - stress tests: not sure I like the timeout in G_USECs
> Have not done anything about this. Can we live with it?

We can!


Other than that it looks generally fine to me and I think we should just get it
in. Seeing that you've got a few tests using that it probably mostly works.

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