[Incubator] autobuild/autotest for OSGeo projects

[Arnulf Christl]

Chris Holmes wrote:
> Hey, I just learned about a great tool to do tests of webapps.
> 
> http://www.openqa.org/selenium/

Hi,
this looks very promising, thanks for the link. We will try it out with 
Mapbender and report to incubation about our experience.

We currently have a set of ~20 web pages with test cases that have to be 
"executed" by a human being before every release and which actually is 
becoming a rather tedious job. So if Selenium does what it proposes it 
can do it would be perfect for our job.

We have a dev, test and prod environment in the web currently operated 
on CCGIS servers. Once we have started the official OSGeo stack we would 
move our "nightly builds" to that server (there is nothing to compile in 
the web application environment so the effort to get going should be 
rather low).

Arnulf.

> You may investigate it's use in mapbuilder, as it can do a lot of things 
> that are hard to test.  It allows you to do tests from a browser, since 
> it runs in a browser.
> 
> There is also:
> 
> http://www.openqa.org/selenium-ide/
> 
> Which allows you to easily make tests by just clicking through the 
> actions that should happen, and then filling in a few fields.
> 
> Chris
> 
> Cameron Shorter wrote:
>> Mapbuilder has an automated build (using ant) but we don't have 
>> automated testing yet.
>>
>> We have started looking into automated testing, but we are still many 
>> months away from having a comprehensive test suite.  (JS tools are a 
>> long way behind java and C tools).
>>
>> Markus Neteler wrote:
>>
>>> Frank, all,
>>>
>>> it would be nice to have an automated build and smoke test within
>>> the OSGeo structure.
>>>
>>> Report from GRASS: we are doing automated builds from CVS every
>>> Saturday, but currently only on x86/Linux inhouse and MacOSX externally.
>>> Once our server grass.itc.it is updated, we can also add mingW builds
>>> (most of GRASS has been ported to MS-Windows native recently).
>>>
>>> The software documentation on the web is rendered in the same
>>> moment when the binary is built.
>>>
>>> A couple of tests have been implemented along with a new
>>> GRASS Test Suite (still external project) which operates similar to
>>> hobu's bot (but yet without IRC):
>>> http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/html/GRASSTestSummary.html 
>>>
>>>
>>> So, things are more or less ready from our side.
>>>
>>> Markus
>>>
>>> On 3/27/06, Frank Warmerdam <warmerdam at pobox.com> wrote:
>>>
>>>> Folks,
>>>>
>>>> I would like to suggest that an automated build and smoke test be part
>>>> of the list of "highly desired features" of an OSGeo project.
>>>>
>>>> By automated build and smoke tests, I mean that project source code
>>>> should be automatically built from CVS/SVN at least nightly and then
>>>> some sort of minimal automatic test be run against that version to
>>>> verify that the current version is at least minimally operational.  
>>>> Ideally
>>>> such build and smoke tests could be done more often, even on 
>>>> demand.  And
>>>> ideally the automatic testing should be fairly extensive.  Furthermore,
>>>> ideally automatic notifications to developers, the developer mailing 
>>>> list
>>>> or somewhere similar should be done when the build or tests fail.
>>>>
>>>> Howard Butler has done a bunch of work with "Build Bot" to make this
>>>> happen for GDAL and is now working on MapServer.  You can see an 
>>>> example at:
>>>>
>>>>   http://gdal.builds.hobu.net/
>>>>
>>>> I am sure that some of the projects already do this.  I think that 
>>>> GeoTools
>>>> has something like this that is somewhat Java oriented.  Is that right
>>>> Jody/Chris?  I also suspect that MapGuide already has this, though I 
>>>> don't
>>>> know if it is aimed at the OS (open source) version of MG.  Projects 
>>>> like
>>>> Mapbender, and MapBuilder that are client browser oriented might not 
>>>> make
>>>> sense to approach in the same way.  Arnulf, Cameron, can you comment on
>>>> whether there would be a meaningful way in which build and smoke 
>>>> test could
>>>> be applied automatically?
>>>>
>>>> My intention isn't to mandate a particular approach to a build and 
>>>> smoke test,
>>>> but rather to push this as a highly desirable aspect of an OSGeo 
>>>> project.  I
>>>> do think that OSGeo ought to provide support to help setup this up for
>>>> projects that don't have their own way they would like to do this.  
>>>> To this
>>>> end Howard has indicated a willingness to setup BuildBot support on 
>>>> an OSGeo
>>>> server at telescience for this purpose.
>>>>
>>>> I would add, that I see this as an action in support of the OSGeo 
>>>> goal "To
>>>> ensure a high degree of quality in foundation projects in order to 
>>>> build and
>>>> preserve the foundation brand."
>>>>
>>>> I have added this as an agenda item for the meeting tomorrow.  If we 
>>>> are
>>>> agreeable on this, my hope is that we can start setting up an OSGeo 
>>>> build
>>>> and smoke test server soon at telescience.  I have cc:ed Howard and 
>>>> also
>>>> Norman (who is responsible for OSGeo use of telescience systems) to 
>>>> this
>>>> end.
>>>>
>>>> Best regards,
>>>> -- 
>>>> ---------------------------------------+-------------------------------------- 
>>>>
>>>> I set the clouds in motion - turn up   | Frank Warmerdam, 
>>>> warmerdam at pobox.com
>>>> light and sound - activate the windows | http://pobox.com/~warmerdam
>>>> and watch the world go round - Rush    | President OSGF, 
>>>> http://osgeo.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
>>> For additional commands, e-mail: incubator-help at incubator.osgeo.org
>>>
>>>
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
> For additional commands, e-mail: incubator-help at incubator.osgeo.org