[gstreamer-bugs] [Bug 585848] Let's revive the test suite

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=585848

  GStreamer | gst-sharp | Ver: git




------- Comment #6 from Sebastian Dröge  2009-06-17 11:49 UTC -------
(In reply to comment #5)
> Arg, a mid-air collision.
> 
> Anyway, below is my response to your comments.
> I was planning on making a new patch series, but if you applied my patches as
> they where (they don't show up on fdo yet), I can address your issues with a
> separate follow-up patch.

Great, I've pushed all changes now :)

================================================================================
> 
> 0001
>   Yeah, I removed test quite liberally.
>   I suppose I can rescue some of what remains after removing the Refcount calls 
>   by adding a check for the number of pads on an element, for instance.
>   Btw, is there a specific reason the Element.Numpads property is gone now?

Ok, would be great if you could attach a new patch which adds all those tests
again then :)

There's no specific reason but I've never used this in C or C# :) If you think
the numpads, numsinkpads, numsrcpads fields of the GstElement instance struct
are useful just file a bug with a patch to add them as readonly properties.

> 0002
>   I just figured that the tests should be written the same as one would write 
>   an application, i.e. without the need for explicit cleanup.
>   I'm not very familiar with the internals of nunit, so I don't know whether or
>   not it GCs after every test.

Well, let's keep it as is then (without Dispose() calls).

> 0003
>   Yes, that certainly is the more cleaner way of accessing the child elements 
>   of a bin. In general however, I have the feeling that this tests depends to 
>   much on the implentation details of GstBin, or is the order of child elements 
>   always garanteed to be the same as the order in which they were added?

Not garantueed by the API but currently it will always be the case ;) I guess
that patch should be changed a bit then...

> 0005
>   This could very well be another idiosyncrasy of Windows, but after the first 
>   DeInit, all subsequent Init()s failed, causing a lot of errors due to a 
>   non-initialized gstreamer. I figured it wouldn't be really nescessary to have 
>   a DeInit after every test, so I removed it. But I should make a test case out 
>   of it and file a bug, if appropriate.

Oh, that's intentional. I thought nunit calls every test in a separate process
like check does. After DeInit() you must not call Init() again. DeInit() is
just for cleaning everything up before the process exits (and is IMHO
absolutely useless).

> Well, marking the tests with the IgnoreAttribute is preferred above commenting
> them out of course. Note that on my machine these two tests not only failed,
> but also caused the entire test suite to crash. By ignoring them I at least get
> a summary of the results, which shows the ignored tests as well, so they can't
> be forgotten.

Ok, fine by me then :) I've enabled all tests now though and none of them is
crashing for me now (after some fixes). If anything breaks for you please file
bugs with backtraces, etc :)

See http://www.mono-project.com/Debugging


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=585848.