kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 10/29/2018 11:02 AM, John Beard wrote:
> On Mon, Oct 29, 2018 at 2:44 PM Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>
>> The PLUGIN object is very much designed for handling files on a per
>> plugin basis.  The files could be on the local file system, Github, or a
>> compressed archive but they are still files.
> 
> Hmm, then maybe I'm thinking on the wrong level (at the PLUGIN level).
> What I really want to achieve is to make it possible to run the
> parsers for all the PLUGINs from any data, not just from the file
> system. The aims here include:
> 
> * Allow an interface suitable for a cut-down parse-only tool, which is
> useful for debugging and instrumentation (GDB, profilers, valgrind,
> fuzzers etc)

The parser (at least the pcb parser I wrote) can be used a parse only
tool.  I cannot speak about the other file format parsers but hopefully
the authors provided low level parse only functionality for testing
purposes.  If not, I'm fine with adding it.

> * Provide framework for command-line tools that can render out
> fooptrints/boards, convert between formats, etc
> * Provide framework that allows up to attach unit tests.
> 
> As you say, this doesn't actually make sense in all cases to work on
> the PLUGIN interface level, as the plugin might have special magic
> ways to get the data, like the Github ones, and you can't always feed
> this data from a test harness.

The github and pcb plugins use the same parser and formatter code but
provide a unique interface to the under lying handling of the files.

> 
> Perhaps I should look at making the PLUGIN derivatives individually
> testable in their own ways, and allow test harnesses to hook in at
> *those* points? For example, the native kicad ones can take an input
> stream of s-exp data, but the Github one might need a mock github-like
> interface so it can optionally "pretend" to talk to github.com for
> when the network side is not the code under test.

This depends on what you are trying to test.  If it's just the parser
and output formatters, then you really don't need the plugin interface.
 If your testing the plugins themselves, then you need to add the
individual test code for each plugin.

> 
> Cheers,
> 
> John
>