Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re^3: Testing IS Development

by dsheroh (Parson)
on Mar 11, 2009 at 12:14 UTC ( #749845=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Testing IS Development
in thread Testing IS Development

I find a significant portions of the "bugs" I make come from making the wrong assumptions

True. OTOH, I find that writing tests forces me to codify and explicitly state my assumptions (even if not in a form the typical end-user would understand), which, in turn, forces me to think about and identify those assumptions.

By making me consciously aware of my assumptions, it serves as a first step towards finding and correcting those which are incorrect. It can also prove useful in implementing the correct behaviours once incorrect assumptions are identified - fixing the tests, if they are well-written, often clarifies what the code needs to do differently.


Comment on Re^3: Testing IS Development
Re^4: Testing IS Development
by JavaFan (Canon) on Mar 11, 2009 at 13:31 UTC
    True. OTOH, I find that writing tests forces me to codify and explicitly state my assumptions (even if not in a form the typical end-user would understand), which, in turn, forces me to think about and identify those assumptions.
    That is only added value if you don't think about assumptions when you are coding.

    I generally do. I don't suddenly consider assumptions more when I code tests than when I write write code. And I'm not talking about assumptions like "snow is always white". I'm talking "assume the data we're interested in is in table X in database Y on server Z" and I assume that because the company wiki says so. But then it turns out that table Z.Y.X is obsolete, and currently the data lives in tables A, B, C on database D on server E. Testing is not going to find that, because when you make your tests, you make mock data from table Z.Y.X. Tests succeed. Code would have worked fine if indeed the report used data from table Z.Y.X. But since the assumption is wrong - the entire chain falls.

      The tests of which you speak here really move into the realm of process data integrity, not the specific testing of any particular application. Like any “manufacturing production-line,” the shop must have the means to validate where the data is actually coming from, and that the correct parameters were specified to the applications that were run. This is an ongoing part of the daily production process.

      This presupposes, of course, that the applications themselves are “known good,” such that it's all essentially worthless if they're not. In other words, they do have a test-suite, it does validate the handling of the data that is flowing through each application, and it does also check that not-valid data will be detected and rejected. Each time an application is deployed to the production environment (by the personnel that is responsible for that ... not the developers themselves), it must clear all tests.

      So, the two concerns are complementary to each other, not exclusive.

        The tests of which you speak here really move into the realm of process data integrity, not the specific testing of any particular application.
        That maybe for the specific example I gave*, but remember, I only raised the issue after the following statement was made:
        The benefit of test driven development is, you *know* your code will work before you ship it.
        which IMO, is so far away from the truth, I wouldn't hire a programmer who thinks that way. I rather have a programmer who's unsure, than one who's convinced to be right, when he isn't.

        *A programmer might also assume the area of a circle is 22/7 times the radius, and write his/her tests accordingly.

Re^4: Testing IS Development
by gwadej (Chaplain) on Mar 11, 2009 at 13:40 UTC

    I had a co-worker many years ago that gave me some really frustrating (and insightful) advice on troubleshooting:

    First, check all your explicit assumptions. Then, check all of your implicit assumptions.

    Obviously, the second one is almost impossible. I find that writing unit tests (and TDD) helps to change some of the implicit assumptions into explicit assumptions. To me, this seems to be a benefit. (Of course, that might just be another implicit assumption.<grin/>

    G. Wade

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://749845]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (11)
As of 2014-09-17 11:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (72 votes), past polls