gtg-contributors team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Mon, Aug 02, 2010 at 06:36:56PM +0200, Luca Invernizzi wrote:
> On Mon, Aug 2, 2010 at 6:31 PM, Bryce Harrington <bryce@xxxxxxxxxxxxx> wrote:
> > On Fri, Jun 11, 2010 at 05:17:55PM +0200, Luca Invernizzi wrote:
> >> FYI, if you want to automatically run tests on commit, give this plugin a shot:
> >> http://doc.bazaar.canonical.com/plugins/en/testrunner-plugin.html
> >
> > Hi, I notice we've got some tests for backend functionality, but should
> > we write tests for browser UI functionality?
> 
> Eh, the problem is: how? The only toolkit I'm aware of is Mago, and
> writing a test seems quite complex. Anyway, the Gedit people have done
> that, so maybe it's doable. We have discussed this topic at GUADEC,
> and the most viable solution seemed to keep the UI part untested and
> as thin as possible.

Oh that's a good thought to check out what gedit does, thanks.  I've not
used mago before but the ubuntu QA team does, and it sounds like it's
been effective for their needs so perhaps a good choice.

I am rather skeptical about the idea that the UI can be kept thin enough
to not test it.  I agree it should definitely be made a lot thinner, and
that much of its functionality should be pushed into more generic and
modular routines that can be tested more easily (liblarch seems to be
going in the right direction.)  However, especially with gtg there is
always going to be demand for UI changes.

In particular, if the plan is to streamline the browser and editor, then
tests can be especially useful, since they could help us catch
regressions in UI functionality as stuff gets moved around, and to give
a good way to track those regressions and give motivation to resolving
them.  Recall with the 0.2->0.3 transition and the new backend code, we
had a lot of regressions that could be found only by rolling the code
into trunk so people would test it and report bugs; it would be painful
to go through all that again now with frontend code transitions.

> > Also, in gtg/GTG/tests/__init__.py most tests are commented out, but
> > there is not an explanation given there - are they broken? or no longer
> > relevant?  If the former, we should fix them rather than just disable
> > them.  If the latter, then wouldn't it be better to delete the code and
> > keep things tidy?  (We have version control if we ever need them again
> > some day.)  Or is there some other reason?
> 
> The tests are fine. The only reason why they're commented is that the
> development in trunk is now concentrated on liblarch, which is the
> only uncommented test. Probably, Lionel commented the other tests
> while writing the ones for liblarch, and forgot to uncomment them
> before committing.

Alright, I'll go ahead and re-enable them in trunk then in this case.

Bryce