Element test framework?

[Russel Winder]

Is there a functional test framework for testing Rust implemented GStreamer
pipeline elements?

For elements that take inputs and deliver outputs there ought to be a way of
specifying test inputs and expected outputs so as to have reproducible tests.

--
Russel.
===========================================
Dr Russel Winder      t: [phone]
41 Buckmaster Road    m: [phone]
London SW11 1EN, UK   w: www.russel.org.uk


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

Hi Russel,

On Tue, 2019-03-12 at 07:53 +0000, Russel Winder wrote:
> Is there a functional test framework for testing Rust implemented
> GStreamer pipeline elements?
>
> For elements that take inputs and deliver outputs there ought to be a
> way of specifying test inputs and expected outputs so as to have
> reproducible tests.

Take a look at the GstHarness API. That seems to be the closest to what
you mention, but is more flexible than that.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Russel Winder]

On Tue, 2019-03-12 at 18:13 +0100, Sebastian Dröge wrote:
> […]
>
> Take a look at the GstHarness API. That seems to be the closest to what
> you mention, but is more flexible than that.

I found gstreamer_check_sys and gstreamer_check so definitely a step forward
:-)

Are there any examples of use to take a look at so as to avoid trying to work
out how to do it from first principles with just the API documentation?
 
--
Russel.
===========================================
Dr Russel Winder      t: [phone]
41 Buckmaster Road    m: [phone]
London SW11 1EN, UK   w: www.russel.org.uk


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Tue, 2019-03-12 at 20:40 +0000, Russel Winder wrote:

> On Tue, 2019-03-12 at 18:13 +0100, Sebastian Dröge wrote:
> > […]
> >
> > Take a look at the GstHarness API. That seems to be the closest to what
> > you mention, but is more flexible than that.
>
> I found gstreamer_check_sys and gstreamer_check so definitely a step forward
> :-)
>
> Are there any examples of use to take a look at so as to avoid trying to work
> out how to do it from first principles with just the API documentation?

Yes, there's a trivial unit test in gstreamer-rs/gstreamer-check and
various bigger tests in gst-plugin-rs. Just grep for "Harness" :)

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Russel Winder]

On Tue, 2019-03-12 at 22:49 +0100, Sebastian Dröge wrote:
> […]
>
> Yes, there's a trivial unit test in gstreamer-rs/gstreamer-check and
> various bigger tests in gst-plugin-rs. Just grep for "Harness" :)

Thanks. I shall peruse and learn.

--
Russel.
===========================================
Dr Russel Winder      t: [phone]
41 Buckmaster Road    m: [phone]
London SW11 1EN, UK   w: www.russel.org.uk


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Russel Winder]

On Tue, 2019-03-12 at 22:49 +0100, Sebastian Dröge wrote:
>
[…]
> Yes, there's a trivial unit test in gstreamer-rs/gstreamer-check and
> various bigger tests in gst-plugin-rs. Just grep for "Harness" :)

I have been following these and seem to have the framework running, which is
great. However I am falling as Hurdle 1, because:

   gstsdr::plugin_register_static().unwrap();

is failing with:

   thread 'can_get_swradiosrc_element' panicked at 'called `Result::unwrap()` on an `Err` value: BoolError { message: "Failed to register the plugin", filename: "src/lib.rs", function: "gstsdr::plugin_desc", line: 49 }', src/libcore/result.rs:997:5

and I am now at a loss as to how to go about unpacking what might be causing
this problem. Any hints on how to debug this sort of thing? The
gstsdr::plugin_desc is:

   gst_plugin_define!(
       "SDR",
       "SDR Plugin",
       plugin_init,
       "1.0",
       "LGPLv3",
       "sdr",
       "sdr",
       "<a href="https://gitlab.com:Russel/gst-plugin-sdr">https://gitlab.com:Russel/gst-plugin-sdr",
       "2018-12-09"
   );

Though I haven't yet created the repository on GitLab.


--
Russel.
===========================================
Dr Russel Winder      t: [phone]
41 Buckmaster Road    m: [phone]
London SW11 1EN, UK   w: www.russel.org.uk


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Fri, 2019-03-15 at 14:34 +0000, Russel Winder wrote:

> On Tue, 2019-03-12 at 22:49 +0100, Sebastian Dröge wrote:
> […]
> > Yes, there's a trivial unit test in gstreamer-rs/gstreamer-check
> > and
> > various bigger tests in gst-plugin-rs. Just grep for "Harness" :)
>
> I have been following these and seem to have the framework running,
> which is
> great. However I am falling as Hurdle 1, because:
>
>    gstsdr::plugin_register_static().unwrap();
>
> is failing with:
>
>    thread 'can_get_swradiosrc_element' panicked at 'called
> `Result::unwrap()` on an `Err` value: BoolError { message: "Failed to
> register the plugin", filename: "src/lib.rs", function:
> "gstsdr::plugin_desc", line: 49 }', src/libcore/result.rs:997:5

Run with GST_DEBUG=6 and provide the log. That will tell us more. But
...

> and I am now at a loss as to how to go about unpacking what might be
> causing
> this problem. Any hints on how to debug this sort of thing? The
> gstsdr::plugin_desc is:
>
>    gst_plugin_define!(
>        "SDR",
>        "SDR Plugin",
>        plugin_init,
>        "1.0",
>        "LGPLv3",

... this is probably the problem. LGPL is a valid string for the
license here, LGPLv3 is not. I'm not sure why we even have a hardcoded
list of acceptable license strings... maybe that should be changed.
--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Russel Winder]

On Fri, 2019-03-15 at 17:34 +0100, Sebastian Dröge wrote:
> […]
>
> Run with GST_DEBUG=6 and provide the log. That will tell us more. But
> ...

Noted for future situations.

> > and I am now at a loss as to how to go about unpacking what might be
> > causing
> > this problem. Any hints on how to debug this sort of thing? The
> > gstsdr::plugin_desc is:
> >
> >    gst_plugin_define!(
> >        "SDR",
> >        "SDR Plugin",
> >        plugin_init,
> >        "1.0",
> >        "LGPLv3",
>
> ... this is probably the problem. LGPL is a valid string for the
> license here, LGPLv3 is not. I'm not sure why we even have a hardcoded
> list of acceptable license strings... maybe that should be changed.

This is definitely the problem. s/LGPLv3/LGPL/ and the code compiles and the
tests run and pass.

Excellent remote debugging. :-)

Thanks, I can now tinker more, and hopefully (!) progress.

--
Russel.
===========================================
Dr Russel Winder      t: [phone]
41 Buckmaster Road    m: [phone]
London SW11 1EN, UK   w: www.russel.org.uk


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel