dogtail-devel Re: gedit tests

[David Malcolm <dmalcolm redhat com>]

On Thu, 2005-10-13 at 09:38 +0200, Paolo Borelli wrote:
> Il giorno gio, 13/10/2005 alle 00.13 -0400, Dave Malcolm ha scritto:
> > [cc'ed to dogtail-devel-list]
> > 
> > I enjoyed reading your blog today, and decided to have a go at
> > implementing some of the test cases you proposed here:
> > http://live.gnome.org/Gedit/TestCases
> > 
> 
> Awesome!

Thanks!   

I've added a link to the test script from that wiki page.

> 
> (I know that the blog entry sounds a bit negative with regard to the
> dogtail-vs-ldtp issue, but let me state that I am impressed by dogtail
> from a technical point of view)

Thanks again.

For myself I feel that dogtail exists to provide an additional tool for
people to use to improve the quality of gnome modules.  It takes a
rather different technical approach to LDTP's framework, and maybe
having both approaches available is good.

Another difference from LDTP is that we're not so focussed on actually
writing tests - I'm hoping that the various package maintainers and
volunteers will write them (want to finish off the test script?  hint
hint!).  Perhaps we'll get it to the point where we can add "writing
test scripts" to the list of ways a GNOME volunteer can help out on a
project.

> 
> > I implemented test 1 and test 3 from your list, and comitted the result
> > here:
> > http://cvs.gnome.org/viewcvs/dogtail-tests/gedit/gedit-saving-tests.py?view=markup
> > 
> > It uses the gedit.py wrapper you wrote, which I imported into CVS here:
> > http://cvs.gnome.org/viewcvs/dogtail/dogtail/apps/wrappers/gedit.py?view=markup
> > 
> > As as experiment I tried using the python unittest module; AFAIK no-
> > one's tried this before with a dogtail script: it seems to work quite
> > well - I wonder what the main dogtail developers think of this approach?
> > 
> > Seems to work, with a couple of caveats:
> > (i) looking at a hexdump of the output file, it has content 'bar\x0a',
> > so I've checked for that in the tests
> 
> gedit (as vim and others editors) always makes sure that the file is
> terminated with a \n otherwise some of the command line utils do not
> work properly.

Thanks for the clarification - sounds like the behaviour and the test
are both correct (and we now have a regression test for that... now to
get it into the tinderbox...)


[snip]