Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: A brief question about testing/best practices

by sundialsvc4 (Abbot)
on Jan 20, 2015 at 18:04 UTC ( #1113913=note: print w/replies, xml ) Need Help??

in reply to A brief question about testing/best practices

Let's say i've written a perl program with classes and methods and subroutines and all that. I have a test program which tests all the class methods and the subroutines, but what about the "glue code" in between it all in the main program?

You need to test, not only the object in isolation, but also its interface to its client, as used by what you refer to here as “glue code.”   Tests are built-up in a sequence, from the atomic to the contextual.

Consider, as an excellent example, the testing strategy used by the venerable DBI, or any similar very complex CPAN module.   The first tests that are run exhaustively test low-level attributes and behaviors of the object(s), including unpublished ones that you do not directly use or see.   Subsequent tests rely upon the fact that all of those more-atomic tests succeeded.   (Such that they might BAIL_OUT if not, as there is truly no point to continue.)

The final tests in the overall test-sequence set up actual scenarios in which multiple calls are made to the object, as a client might do when that client is doing either the right-thing or the wrong-thing.   They are mimicking the “glue code.” The client should find that sequences of calls which are supposed to be made in-sequence produce the intended result, and that sequences which are not valid are, in fact, detected and rejected in the proper way.   If the contract that the object makes with its users are that certain combinations of events are invalid, then the object must enforce that contract, and so you must by testing prove that it [still] does.  

It is frequently suggested that you should “write the tests first,” and use those tests to specify (and then, to demonstrate) what the object is supposed to do.   Now, go write the code that passes 100% of those tests, first to last, top to bottom, stem to stern.   I have tried that approach, and found that it worked.   That it yielded trustworthy code ... and that it compelled me to think the thing all the way through before I started writing.   We all know the old saw that says, “the last 20% of the code takes the other 80% of the time.”   Well, I’ve found that this technique significantly reduces that effect.   Development proceeds, at first blush, “more slowly,” yet it proceeds much more surely.

  • Comment on Re: A brief question about testing/best practices

Replies are listed 'Best First'.
Re^2: A brief question about testing/best practices
by Amblikai (Scribe) on Jan 20, 2015 at 20:38 UTC

    This is excellent advice, thanks.

    With regards to writing all the tests first, i've been reading up on Test Driven Development and this seems like the core point. Does this work out in practice? I know that when i start a project i tend to jump in and start coding! Half out of excitement and half out of necessity.

    Also, how do i apply this method to existing scripts where i don't have test written?

    Are there any good documents or links you know of that show the best approach to take?

    Thanks again!

      In my experience – and I can only speak from my experience – the answer for me is:   “yes, but it’s not a religion.”   On the one hand, there is always the (legitimate) urge to “get started.”   On the other, there is the (also legitimate) concern that it takes exactly the same amount of time to write source-code that you won’t use, as it does to write source-code that you will.

      A very interesting viewpoint on this picture was described in a book, Managing the Mechanism, which so far as I know is available right now only on the Kindle.   The premise is that, when you are writing software, you are constructing a machine ... and, not just “a machine,” but “an automaton.”   A mechanical machine that has to successfully play Chess and win.   When you frame the challenge of software in that way, the importance of specification and testing becomes much more intuitive.

      I don’t reach for textbooks to tell me what to do.   When faced with a task of any significant complexity, I definitely do find a test-driven approach to be beneficial.   Why?   Because I know the value of actually being able to use myModule; with the same degree of confidence (and the same technical justification for holding such confidence ...) as I know that I am able to do when I use DBI;.

      When you use a battle-tested CPAN module such as this one, you do not give a second thought as to whether this module will actually perform as the perldoc promises you that it will.   And, if you have ever paid attention while that module and its many brethren are being installed, you will know why this is so.   You will recognize the need to be able to make the same statements and to have the same assurances with regard to “the stuff that you wrote.”

      So ... “it’s not a religion, but it is a Best Practice that can be routinely achieved.”   With a little extra effort.   Which is worth it.

      That has been my experience, anyway.   But always keep in mind that these are simply guidelines.   Strategies, if you will.   Strategies that have proven useful-enough to other people (like me), that they would recommend those strategies to others.   Your Mileage May Vary,™ but My Mileage™ so far has been pretty darned good.

        And testing is not an afterthought ... it is a fundamental of the design. "Computer software," after all, merely consists of (millions of ...) "yes-or-no" instructions that are given to a microscopic silicon chip.


        Err, ..."literally" rolling on the floor...

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2021-01-17 00:12 GMT
Find Nodes?
    Voting Booth?