Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
On the question itself:

In that situation, I would add tests as convenient in any available free time (hah!) until a bug was found or the code needed to be changed for any other reason.

If the change is triggered by a bug, create one or more test cases to demonstrate the bug and prove both that it exists and that you know how to trigger it before making any changes to the code. (Proponents of test-driven development would classify "it should have a new feature, but doesn't" as a bug and perform this step for any change. While I find TDD to be a useful practice in many cases, you can still do good testing without embracing it.) These tests will tell you when you have fixed the bug.

Regardless of the cause of the change (bug, new feature, whatever), create additional tests for each subroutine before making any changes to that subroutine. These tests should verify that, for a full range of both valid and invalid inputs, you get the expected output. These tests will tell you whether you broke anything new in the course of making the changes (and you may discover some additional bugs in the process of writing the tests).

By creating tests as needed before making any changes, you will eventually build up a solid test suite for your code, or at least for the portions which are subject to change.

On the side question of users not running the tests:

That's not really a major issue in most cases. Tests are tools for the developer's use and, in most cases, knowing that they run successfully on your machine(s) is sufficient.

But there are always the exceptions, when some environmental issue brings out a bug on a user's system which doesn't occur on yours. In these cases, you need to identify the environmental issue and attempt to duplicate it on your development system in order to debug it - this holds regardless of whether you're doing automated testing or not.

However, if you have your test suite, you can turn that into a compiled .exe and ask the affected user(s) to run it. If any tests fail there, then that gives you a head start towards isolating the problem and identifying its underlying cause. And, as with any bug, once you're able to emulate the cause and trigger the bug in your test suite, it will stay there and help to avoid the introduction of similar bugs (or re-introduction of the same one) in later versions of the code.

In reply to Re: how to begin with testing? by dsheroh
in thread how to begin with testing? by stinkingpig

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, 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, 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.
  • Log In?

    What's my password?
    Create A New User
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others musing on the Monastery: (3)
    As of 2018-05-23 06:27 GMT
    Find Nodes?
      Voting Booth?