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
