On Wed, 5 Mar 2014 12:23:31 -0700
Tim Flink <tflink(a)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