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]" 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: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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.