[lm-sensors] regression test script for sensors output

[Mark M. Hoffman]

Hi Jim:

Thanks for the links...

> Mark M. Hoffman wrote:
> > Do you have any experience with these Perl modules... ?
> >
> > 	test::cmd
> > 	test::simple
> > 	test::harness

* Jim Cromie <jim.cromie at gmail.com> [2006-09-07 10:08:55 -0600]:
> one word version - yes.
> 
> http://search.cpan.org/~knight/Test-Cmd-1.05/Cmd.pm
> last updated in 2001, but given its tight focus on testing executables,
> I dont see its age as a problem.  The Doc at the link is good.
> 
> http://search.cpan.org/~mschwern/Test-Simple-0.64/lib/Test/Simple.pm
> slightly simpler version of test code used to validate perl itself, which
> is well developed and mature (100K tests, and increasing..)
> 
> http://search.cpan.org/~petdance/Test-Harness-2.62/lib/Test/Harness.pm
> This is more infrastructure stuff, you dont need it until you need more than
> Test::Simple, Test::More do by themselves ( Harness complements them, 
> not replaces them)
> 
> 
> http://search.cpan.org/~mschwern/Test-Simple-0.64/lib/Test/Tutorial.pod
> good orientation to the perl Test::* facilities
> 
> > I'm working up a regression test for the libsensors config file scanner.  At
> > the moment, Perl with those modules looks like an easy but flexible way to
> > organize it. 
> Id agree with that.
> 
> Is the scanner observable & controllable at a unit level ?
> 
> [...]
> 
> So, back to the scanner ..
> Its 'output' is an expression tree in memory thats used to compute 
> user-facing
> numbers by sensors, ie its not directly observable, except insofar as it 
> affects
> sensors output.

To be precise: the scanner, as generated by flex, is a non-reentrant function
[in this case, sensors_yylex()] that is called repeatedly to separate the input
into tokens.  One token is returned with each call; the next call will pick up
where the last left off.

Hmmm, another part of its 'output' is a global variable that it updates with
each call:  the current line number.

> What are you looking to test ?
> - that scanner rejects bad configs ?
> - that changes in the config-file input yield commensurate changes in 
> sensors output ?
> - that setting alarm thresholds below/above current measurements results 
> in 'ALARM's ?
> - etc ..

That's a fair question.  The intention was that this would be a unit test
for the scanner itself - nothing more.  But if I use sensors(1) to drive
that, the tests themselves will require maintenance as that program's 
output format changes, etc.  Plus it will depend on what hardware you have;
or it will need scripting to set up i2c-stub, blah blah blah.

So I'll write a simple 'driver' program for the scanner instead.  It will just
send each token (and its line number) to stdout.  That way Perl's Test::Cmd
will work very nicely.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com