Yes, now that GStreamer core/-plugins-base/-python (and I should do
the same for GNonLin) are frozen and being pre-released we should
feature-freeze pitivi and spend the next week or two (until the modules
mentionned above are released) ironing out bugs.
On Tue, 2009-07-14 at 17:16 -0700, Brandon Lewis wrote:
> I understand from reading the IRC back-scroll that we're heading into a feature
> freeze and then testing / bug squashing phase. I've noticed lately that our test
> coverage isn't all that good, as quite often every test in make check will pass
> but the first thing I get when I start pitivi interactively is a huge traceback
> ending in some part of pitivi core. I feel what's missing is a set of high-level
> tests that hit all the code-paths we take into core from the UI, perhaps
> paralleling the QA scenarios we have on the website. I started working on this
> but I'm wondering about a couple of things:
> 1) It would be useful to have some media files for tests involving the source
> list, but how do we handle this with version control? It seems like a bad idea
> to check even small media files into git, but maybe I'm mistaken about this.
I'm fine with having media files for doing interactive testing of
pitivi... but it might be better to not force everyone to have to
download those (small) media files if they only want to test out pitivi.
Maybe an alternative would be to have an optional git-submodule to
contain those media files and only those people interested in ui testing
(like the core developers and peripheral testers) would grab.
> 2) Some parts of pitivi depend on having a running gobject.MainLoop, which is
> currently implemented only in InteractivePitivi. Using this starts the GUI, and
> it is my understanding that we do not want any of the tests to depend on the
> GUI. So should I instead factor the code which launches the MainLoop into the
> base application class? This wouldn't be entirely wrong since GStreamer also
> depends on having a running mainloop.
Yes, in order to use GStreamer you need a mainloop... which doesn't
need to be a GObject MainLoop (you can create your own 'mainloop' and
poll the bus yourself). The problem is more pitivi that relies heavily
on GObject's mainloop (due to being almost entirely event-based, even
without using the UI).
Maybe the Application class should be refactored a tiny bit to allow
an intermediate interactive class that starts a mainloop but doesn't
start the UI.
As for the actual UI testing... What Nathan recommended (LDTP) seems
to be the current accepted way of doing high-level UI testing. A first
start would be to write tests for all the use-cases mentionned in Jeff's
online manual (starting from importing sources all the way to the
advanced editing features), making sure that what is stated in the
manual works properly.
One thing we'll need to make sure LDTP supports is whether we can also
test non-UI stuff (like the current unit tests) intermingled with the UI
testing (Ex: Do a source move graphically, make sure the source has
graphically move, but also make sure that the internal values for
track/timeline objects have also moved correctly).
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> Pitivi-pitivi mailing list