The central point of TDD (at least as I understand it) is to write tests which verify your assumptions about what your code will do. This way you have a way of verifying that your code behaves as you would expect it to.

Now, at this point, I realize that before I get much further, I have to write like 3 more tests to get anywhere close to Devel::Cover's strident call. And, that's just with the minimum needed to satisfy the first test!

Thats the thing about Devel::Cover, it shows you exactly what you test code is running. Testing your "assumptions" will likely not test all your code, and this is where Devel::Cover comes in.

Personally, my approach is not true TDD. I like to write some code before I write tests so that I have something to work off of. At that point I proceed going back and forth between writing code and tests, sometimes tests first, other times code first depending upon where my inspiration is taking me. I still consider this TDD since test writing is still an integral and driving part of my process.

Only after I feel like I have something reasonably completed (not finished, but complete for that stage of development) do I run Devel::Cover. At that point I start writing tests again to fill in the missing coverage.

Now the reason I wait until (almost) the end to run Devel::Cover is that many times code which may not be run (covered) in one set of tests, will be run (covered) with another. So many times it may not make sense to write tests to cover that code at that point anyway.

The process of writing tests for code which is not covered under my basic "assumptions" usually leads to several things.

  1. I realize ways in which my code can be used/abused that I have never thought of. This sometimes leads to adding error checks, or even re-writing whole sections of code to be more in line with my assumptions.
  2. I sometimes find some unreachable code. Sometimes I realize I can delete this code, and other times I realize that I need to re-write things so that the code is actually reachable.
  3. I find lots of fodder for the CAVEATS section of my documentation :)
The level of insight into my running code which Devel::Cover provides, is IMO what makes it such a valuable tool. I have found that since I have been using Devel::Cover more, the coverage % on the first Devel::Cover run has gone up. So in a way it could be said that Devel::Cover has helped me become a better test-writer and therefore a better programmer.

-stvn

In reply to Re: OT: TDD question by stvn
in thread OT: TDD question by dragonchild

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.