Linux-ext4 Archive on lore.kernel.org
 help / color / Atom feed
From: <Tim.Bird@sony.com>
To: <brendanhiggins@google.com>
Cc: <tytso@mit.edu>, <skhan@linuxfoundation.org>,
	<yzaikin@google.com>, <linux-kselftest@vger.kernel.org>,
	<linux-ext4@vger.kernel.org>, <adilger.kernel@dilger.ca>,
	<kunit-dev@googlegroups.com>
Subject: RE: [PATCH linux-kselftest/test v2] ext4: add kunit test for decoding extended timestamps
Date: Fri, 18 Oct 2019 01:30:42 +0000
Message-ID: <ECADFF3FD767C149AD96A924E7EA6EAF977D01A2@USCULXMSG01.am.sony.com> (raw)
In-Reply-To: <CAFd5g44txp2j9May1YD9rq6bcNnCx_JKNNmnsrr+JG+cTX0chg@mail.gmail.com>



> -----Original Message-----
> From: Brendan Higgins 
> 
> On Thu, Oct 17, 2019 at 3:25 PM <Tim.Bird@sony.com> wrote:
> >
> > > -----Original Message-----
> > > From: Theodore Y. Ts'o on October 17, 2019 2:09 AM
> > >
> > > On Wed, Oct 16, 2019 at 05:26:29PM -0600, Shuah Khan wrote:
> > > >
> > > > I don't really buy the argument that unit tests should be deterministic
> > > > Possibly, but I would opt for having the ability to feed test data.
> > >
> > > I strongly believe that unit tests should be deterministic.
> > > Non-deterministic tests are essentially fuzz tests.  And fuzz tests
> > > should be different from unit tests.
> >
> > I'm not sure I have the entire context here, but I think deterministic
> > might not be the right word, or it might not capture the exact meaning
> > intended.
> >
> > I think there are multiple issues here:
> >  1. Does the test enclose all its data, including working data and expected
> results?
> > Or, does the test allow someone to provide working data?  This alternative
> > implies that either the some of testcases or the results might be different
> depending on
> > the data that is provided.  IMHO the test would be deterministic if it always
> produced
> > the same results based on the same data inputs.  And if the input data was
> deterministic.
> > I would call this a data-driven test.
> >
> > Since the results would be dependent on the data provided, the results
> > from tests using different data would not be comparable.  Essentially,
> > changing the input data changes the test so maybe it's best to consider
> > this a different test.  Like 'test-with-data-A' and 'test-with-data-B'.
> 
> That kind of sound like parameterized tests[1]; 

...

> 
> [1] https://dzone.com/articles/junit-parameterized-test

Both Iurii and you pointed me at parameterized tests.  This sounds like
what I am talking about.  We have a lot of infrastructure for these concepts in Fuego,
but it's called something different.

I'm not sure if I should feel smart for having developed some of these concepts
independently or dumb for not having known about this (apparently) standard
nomenclature. ;-)

Thanks for the reference!
 -- Tim


  reply index

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10  2:39 Iurii Zaikin
2019-10-10  3:46 ` Tim.Bird
2019-10-10 16:45   ` Iurii Zaikin
2019-10-10 20:29     ` Tim.Bird
2019-10-10 23:49       ` Iurii Zaikin
2019-10-10 17:11 ` Shuah Khan
2019-10-10 22:13   ` Iurii Zaikin
2019-10-11 10:05     ` Brendan Higgins
2019-10-11 13:19       ` Theodore Y. Ts'o
2019-10-12  2:38         ` Iurii Zaikin
2019-10-16 22:18         ` Brendan Higgins
2019-10-16 23:26           ` Shuah Khan
2019-10-17  0:07             ` Iurii Zaikin
2019-10-17 12:08             ` Theodore Y. Ts'o
2019-10-17 22:25               ` Tim.Bird
2019-10-17 22:56                 ` Theodore Y. Ts'o
2019-10-17 23:40                   ` Tim.Bird
2019-10-18  1:40                     ` Theodore Y. Ts'o
2019-10-18  2:40                       ` Tim.Bird
2019-10-18 15:27                         ` Theodore Y. Ts'o
2019-10-18 20:24                           ` Shuah Khan
2019-10-24  1:30                             ` Brendan Higgins
2019-10-18  1:12                 ` Brendan Higgins
2019-10-18  1:30                   ` Tim.Bird [this message]
2019-10-17 22:49               ` Shuah Khan
2019-10-17 23:07                 ` Iurii Zaikin
2019-10-17 23:12                   ` Shuah Khan
2019-10-17 23:27                     ` Iurii Zaikin
2019-10-17 23:42                       ` Shuah Khan
2019-10-17 23:54                       ` Tim.Bird
2019-10-17 23:59                         ` Shuah Khan
2019-10-18  0:11                         ` Iurii Zaikin
2019-10-18  0:38                           ` Tim.Bird
2019-10-18  1:06                             ` Iurii Zaikin

Reply instructions:

You may reply publically 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=ECADFF3FD767C149AD96A924E7EA6EAF977D01A2@USCULXMSG01.am.sony.com \
    --to=tim.bird@sony.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=brendanhiggins@google.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=tytso@mit.edu \
    --cc=yzaikin@google.com \
    /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

Linux-ext4 Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-ext4/0 linux-ext4/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-ext4 linux-ext4/ https://lore.kernel.org/linux-ext4 \
		linux-ext4@vger.kernel.org
	public-inbox-index linux-ext4

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-ext4


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git