D19 Comments and Diff

[Tim Flink]

On Wed, 5 Mar 2014 12:23:31 -0700
Tim Flink <tflink at redhat.com> wrote:

<snip>
 
> > That's true, but if we have zero-failed-test policy, why does it
> > matter? If you patch introduced a problem, you need to fix it, and
> > you might discover another one once you do. Yes, it might be a
> > sequence of steps rather than seeing everything at once, but at the
> > benefit of test readability (items logically grouped together,
> > rather than one assertion per method). Also, I'm testing a part of
> > a single function in one method, it's not like it can have large
> > consequences. I understand why splitting larger pieces to smaller
> > pieces is good, but I don't understand why splitting it into one
> > line per method is good. All of those tests are trivial - simple
> > functionality of simple methods.
> 
> One of my counter-points here is that if the tests are so trivial, do
> we really need to have them? After a certain point, we can add tests
> but if they aren't incredibly meaningful, we'd just be adding
> maintenance burden and not gaining much from the additional coverage.
> 
> > They have a dozen lines, a few asserts. An error in the
> > first line can hide an error or two in the remaining eleven lines,
> > but you'll discover that soon enough, once you fix the code and run
> > the tests again. Is that a problem?
> 
> In this particular case, not a huge problem - the code under test is
> relatively trivial. That being said, I don't really want to start off
> with tests that

Complete thoughts do tend to help ...

That being said, I don't really want to start off with tests that are
putting too many asserts into the one test. Some combinations are fine
but I'd prefer erring on the side of separating things out a bit too
much for now rather than risk setting an example of large, monolithic
tests.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20140305/b5b9e78e/attachment.sig>