public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: ebiederman@lnxi.com (Eric W. Biederman)
To: Jared Hulbert <jaredeh@gmail.com>
Cc: MTD List <linux-mtd@lists.infradead.org>
Subject: Re: Unit test for cfi_cmdset_0001.c
Date: 27 Jan 2005 23:11:02 -0700	[thread overview]
Message-ID: <m33bwmw0ax.fsf@maxwell.lnxi.com> (raw)
In-Reply-To: <6934efce05012717207271fb10@mail.gmail.com>

Jared Hulbert <jaredeh@gmail.com> writes:

> I plan on creating a unit test based on cutest.sourceforge.net for
> cfi_cmdset_0001.c.
> In order to stub out the various functions inside I will have to:
> 
> 1. Manually strip out functions for each version.
> 2. Add #if''s
> 3. fork this file into 2-3 files.
> 
> I prefer option 3.  As it seems cleaner to me and more maintainable. 

Why would you even need to split the file into multiple pieces to
provide test wrappers?  cutest does not seem to add that requirement.
I'm not certain what value cutest actually provides.  A test harness
that  would require the source file to be split into multiple pieces
seems to indicate a flaw in the test harness.

> The reason for the unit tests is to help us find bugs in the code
> paths not easily tested and to enable more rapid updates for new flash
> or features mtd doesn't currently support.

The hardest code paths to test are code paths for hardware that
is usable but not quite right.  How do you plan on testing that?

Which features for flash chips are you thinking about supporting that
are not currently supported? 

Eric

  parent reply	other threads:[~2005-01-28  6:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-28  1:20 Unit test for cfi_cmdset_0001.c Jared Hulbert
2005-01-28  2:12 ` Nicolas Pitre
2005-01-28  2:16 ` Josh Boyer
2005-01-28  6:11 ` Eric W. Biederman [this message]
2005-01-28 19:47   ` Jared Hulbert
2005-01-28 20:59     ` Nicolas Pitre
2005-01-29  1:48       ` Jared Hulbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m33bwmw0ax.fsf@maxwell.lnxi.com \
    --to=ebiederman@lnxi.com \
    --cc=jaredeh@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox