Joep Suijs wrote:
> Until now, I assumed we'd only need two files to compose a test:
> - a board file, which tells the type of pic, it's configuration (like
> type and frequency of the oscillator) and it's connections.
> - a test file, which tests a specific function.
>
> But in some cases, there are more options. Some interfaces, like i2c
> and serial, have multiple libaries. So this gives us 3 files: the
> board, optional: the interface and then the test. How do we deal with
> this?
>
> 1. create a test file for each interface
> This gives more files with similar code. Not ideal and a bit
> error-prone but not that bad.
>
> 2. adapt the test file when you want an other interface
> Quick and dirty (mostly dirty). Not suitable for automated tasks.
>
> 3. have the to-be superscript support more then 2 files to compose a
> test (3 or maybe more?).
> Looks at the best option at first glance. But it also means we can not
> define tests as simple 2-dimensional (test x on board y). The benefits
> might not add up to the costs of the complexity induced.
The 'intermediate' libraries (prerequisites for other libraries) will
generally be for relatively simple common 'lower layer' services and
should have been tested independently. Thus these libs themselves can be
considered transparent (not take place in the test of the higher level
library). But of course the interface between higher level and lower
level library is part of the test of the higher level library.
This means we have always 'two-dimensional' test setups: highest level
library and hardware.
Regards, Rob.
--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jallib" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jallib?hl=en
-~----------~----~----~----~------~----~------~--~---
