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

Re: Universal test flag

by zwon (Monsignor)
on Jul 17, 2012 at 13:24 UTC ( #982237=note: print w/ replies, xml ) Need Help??


in reply to Universal test flag

This approach has a problem -- you won't be testing production code with this flag set e.g.:

if ($self->_test_mode) { # test_code } else { # production code, not tested }
If code needs to know that it is being tested, I suspect something wrong with the interface. Also, may be you should have a look onto mocking modules like Test::MockObject.


Comment on Re: Universal test flag
Download Code
Re^2: Universal test flag
by ait (Friar) on Jul 17, 2012 at 14:24 UTC
    If code needs to know that it is being tested, I suspect something wrong with the interface.

    Probably so, and in theory everything sound nice, but in real-world every-day coding, with a team of coders, and with time and budget constraints, this is by far the common case. You need to be able to test things while skipping others that don't concern that particular aspect that you are working on or testing.

    Example: you are testing a class that invokes an external service to send an SMS, and the SMS gateway has no test mode, so it costs you money. Your class does a hundred things besides sending the SMS and has a lot of business logic and you only want to skip the SMS sending part to test this logic. Maybe the SMS sending logic was encapsulated in a class (in which case could be mocked) or maybe it's part of the same class on a sub and can't be mocked. Like this one, there are a many day-to-day scenarios where you want to skip over some part of the code just o test the overall logic.

    Refactoring to make code perfectly testable is not always an option, in fact, it rarely is, at least in large projects. The code is far from perfect and you have to make the best of it and try to test it as best you can within the time and budget constraints that a particular project allows.

      Refactoring to make code perfectly testable is not always an option...

      ... but writing more code is an option?

      If you have to write extra code in the code you're testing that only gets executed in test mode, I think your confidence in the test results goes down.

      Refactoring to make code perfectly testable is not always an option, in fact, it rarely is, at least in large projects

      The purpose of refactoring is to make code structure optimal, testability is just a side effect. And it is especially important for large projects, without maintaining code structure you will soon finish with spaghetti which will take years to unravel. Particularly, if you have classes which do hundred things and send SMSes, it does sound alarming.

      chromatic and zwon:

      Obviously your world seems more perfect than ours, but the hard truth in the commercial world is that there is always a tradeoff between quality and the amount of money and time available. Most of the projects today are constrained in both, and you must quickly adapt constantly changing business conditions, so refactoring always falls in second place, after you get the (ever changing) functionality pinned down.

      Testing on the other hand is paramount to make sure each piece does what it should and all the pieces fit together when several people are working on the same project. Of course, code must be good enough to be tested but it surely doesn't have to be perfect.

      Sure, software is perfectible if you have enough time and resources, but the cold hard truth is that in most situations customers are not willing to pay the extra money for perfect code and their budget only allows for "good enough". IMHO, the truly successful business projects are able to deliver in time and money with good enough code to get business flowing and creating the cash flow necessary to eventually perfect the code.

        the hard truth in the commercial world

        Oh, you apparently think that I'm living off charity and only write abstract examples ;)

        refactoring always falls in second place, after you get the (ever changing) functionality pinned down

        refactoring is not something you do after implementing functionality, it is something you do to implement functionality in a most efficient way (and so save time and money)

        Obviously your world seems more perfect than ours, but the hard truth in the commercial world is that there is always a tradeoff between quality and the amount of money and time available.

        I've been in management for five years now. I've been doing automated testing for fourteen years now.

        Now that we're past the credential waving protocol, let me paraphrase what I said, lest it be waved away under the flag of "We don't have time to do it right. We're doing Serious Business".

        Of course, code must be good enough to be tested but it surely doesn't have to be perfect.

        If you run your code differently under testing than you do in deployment, your tests probably aren't testing what you care about.

        I didn't use the word "perfect". Please don't read into what I wrote; you'll confuse things.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2014-12-18 00:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (41 votes), past polls