Re: Unit test for cfi_cmdset_0001.c

[Jared Hulbert <jaredeh@gmail.com>]

Wow!  Lots of sceptics!   Help!  Anybody who thinks this is an idea
that is promising please chime in. :)

Hmm, Let me try to explain a little better.

Consider cfi_cmdset_0001.c: 
cfi_intelext_write_buffers() calls cfi_intelext_write_words() and
do_write_buffer()

In order to properly unit test you'd need to stub out
cfi_intelext_write_words() and do_write_buffer().  For those that
don't understand stubbing out this means creating a phony functions to
accept input and give output based on the test condition.  This allows
you to test code paths that are improbable under nomial conditions or
very difficult to test with other methods.  But if the
do_write_buffer() is compiled into the same .o as
cfi_intelext_write_buffers() I'm not sure how to link to my stub
do_write_buffer() instead of the real one.  That is the problem that
drives my original question about #if's, forking the files, etc.

Because there are macros between this driver and any real hardware it
should be rather easy to test various states and see at least the
sequence of events the hardware will see.  This allow you to test for
hardware that does not exist or is not really worth it.  Certianly it
is not a magic bullet, it is only as good as your tests, and doesn't
find timing bugs or bugs related to multitasking etc.

I did it with a file system at work it was very useful.

,JAred