www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/08/09/14:24:48

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <57AA1F5C.3000007@xs4all.nl>
Date: Tue, 09 Aug 2016 20:22:20 +0200
From: "Bert Timmerman (bert DOT timmerman AT xs4all DOT nl) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] upgrading the testing framework for pcb, please object
now
References: <CAC4O8c81kb=9Tei2judPeYJKiq51WpZ154JVuakqW=0RXx6bCQ AT mail DOT gmail DOT com>
In-Reply-To: <CAC4O8c81kb=9Tei2judPeYJKiq51WpZ154JVuakqW=0RXx6bCQ@mail.gmail.com>
Reply-To: geda-user AT delorie DOT com

Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> So not having heard back on the question of how we wanted to do tests,
> I decided it would be better to go with glib-based g_test_* testing,
> instead of the end-to-end tests in the tests subdir.  The main reason
> is that this will make it possible to directly test interfaces that
> aren't exposed as actions.
>
> Currently only pcb-printf uses this approach, and since it's a
> stand-alone interface it (correctly) doesn't create a full pcb context
> for it's tests to run in.  However, many other tests require more
> context.
> Therefore what I intend to do is:
>
> * leave the existing unittest about as it is.  All tests of
> stand-alone modules in pcb can go there
>
> * make a new main-contex_tests.c or something that provides everything
> you would find in a running pcb instance except the gui stuff.  I've
> already got this working it just needs split off from the existing
> unittest and some cleanup.
>
> If this isn't ok please let me know now.
>
> Britton
>
>    
Hi Britton,

Sorry for the delayed response, a busy project at the day job is eating 
all my free cycles.

FWIW, here goes some of my rants:

If we use the existing units test methods for testing hids and GUIs, 
would that imply we also need all the dependencies for testing GUIs not 
suported by the OS, for instance: do we need to have GTK installed for 
testing a "no-gui" target ?

Or is a modular testing approach more flexible ?

Test if the framework is availble and usable before commencing the tests 
for that framework.

Would depending on a glib based test harm us on platforms (OS'es) not 
supporting glib or such ?

Just a couple of things that came up ... have to dig deeper into the 
testing methods.

Kind regards,

Bert Timmerman.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019