[lm-sensors] regression test script for sensors output
jim.cromie at gmail.com
Thu Sep 7 18:08:55 CEST 2006
Mark M. Hoffman wrote:
> Hi Jim:
> * Jim Cromie <jim.cromie at gmail.com> [2006-08-31 12:33:17 -0600]:
>> attached script reads `sensors` output, compares to file content
>> (which should contain sensors output from baseline driver, before you hack)
> Hey, thanks for doing that - it will be useful.
It may not work well for cases with 2+ chips being reported, since I dont
have such a mobo, but its probably extensible w/o much effort.
(anybody want to post such ouput ?)
I didnt try to reduce it to yes/no tests, which is what most of perl's
Test::* modules do.
> Do you have any experience with these Perl modules... ?
one word version - yes.
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.
slightly simpler version of test code used to validate perl itself, which
is well developed and mature (100K tests, and increasing..)
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)
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 ?
Let me elaborate by example...
* my regression script tests end-to-end;
driver + sysfs-interface + sensors read of it --> results (saved to file)
It wont tell you where things may be broken.
I thought briefly about testing the attr-files directly, but punted once
I saw that the /sys/<path> to use wasnt entirely obvious from the
Adapter: ISA adapter
IOW, I didnt see a 1:1 between the former and "2c-9191/9191-6620"
* I could have made my script more testable by accepting 2 files of
and testing them for 'equivalence', rather than running `sensors` for
So, back to the scanner ..
Its 'output' is an expression tree in memory thats used to compute
numbers by sensors, ie its not directly observable, except insofar as it
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 ..
> By contrast, Dejagnu is extreme overkill. Are there any other
> mechanisms I should consider?
If youre looking for non-perl test tools, there are probly many,
but I dont know any of them. For me, perl is enough.
> Thanks & regards,
More information about the lm-sensors