www.delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/08/09/16:41:30

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=E/7VoWCj9zeq6J/4K6FuNg76BJJyYOcOb0AXsvOC+6w=;
b=ofWNQbX4fAAXS0zWkEV1xhiI1RwkCfkdWjOOKCLm5ZPp09hROWr//Za+WJFEkCsqKi
yNhlASQ4/866kokbJj066Z7MRE8YMOpPN2ZF9n1K6jmB1a2L+aHZ35QpoFHeVaSPuwv1
25VGumPqA2X/z1dc19hCJpx03tzpesJx4Zkfz5kRRbTgEU/lJKqWs9j7Zbu77fo1icN7
9Shf7pDjCvWmPr1E46oUTYwUMsVFXoQCEYPidtXXzmXb4k2mBSGdNdwH2lyp8JqOIR0t
Bc32jwd6vNFQT+9eRlIgaGtdKYiBo4s/Klvxa49HIF3npagFGn4tqZw3ckIXYzmRjlgP
3a7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=E/7VoWCj9zeq6J/4K6FuNg76BJJyYOcOb0AXsvOC+6w=;
b=KgPFLoZ054h0ePTFLpnnhBOcxhEWVlRBwhdCXMMwoIEVi3Vps+crHP1noQTIHEx/2y
CR9tqzhxsto+xSNkqdP6AnV6TnWRZRqQBY1dbjDWu6clFT9ZREGFvrkgl7x6mjL6uoi1
LRZGSOlmvEPnJNrRhVwxQQxDn64779Q1rYpQLseTr3+VBtZkfn9M/xYnxlh5LW2dP2Ku
eCz0xmxndIOQD3z0QGCTw5h192fX7EPnNd9h+UIPAUwrBT0BC2C2yHNjXXOjSHeezMLc
c3F44DyTnMh18AzaO+ObFee+IT9mlV01LSasgbwgCFGhVSHc4J7akORciMQXKAU4yRbp
FPzw==
X-Gm-Message-State: AEkoouvrW7WyEUnMGHD50WiT7mM+nz4NznnoitUD+ctEtrwcrF9IFid7QvYi9n0qlhhfLlTHLAGMAXNAuF/XhA==
X-Received: by 10.194.38.166 with SMTP id h6mr233391wjk.101.1470775150647;
Tue, 09 Aug 2016 13:39:10 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <57AA1F5C.3000007@xs4all.nl>
References: <CAC4O8c81kb=9Tei2judPeYJKiq51WpZ154JVuakqW=0RXx6bCQ AT mail DOT gmail DOT com>
<57AA1F5C DOT 3000007 AT xs4all DOT nl>
From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date: Tue, 9 Aug 2016 12:39:10 -0800
Message-ID: <CAC4O8c_5fgo9bDSw4tuTxhiKNhU5HJKcVav72GXYE+iTfnKhhQ@mail.gmail.com>
Subject: Re: [geda-user] upgrading the testing framework for pcb, please
object now
To: geda-user AT delorie DOT com
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Tue, Aug 9, 2016 at 10:22 AM, Bert Timmerman
(bert DOT timmerman AT xs4all DOT nl) [via geda-user AT delorie DOT com]
<geda-user AT delorie DOT com> wrote:
> 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 ?

It would be best to avoid this, and it should be fairly easy to do so.
I haven't not
had gtk installed and don't know how the glib-based tests behave in that
context at the moment though.

> Or is a modular testing approach more flexible ?
>
> Test if the framework is availble and usable before commencing the tests for
> that framework.

Automated testing of the GUI itself is not on my radar at the moment, I don't
know about other people.

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

I don't think there are any such platforms are there?

Britton

- Raw text -


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