Testing a Request

Discussion of testing theory and practice, including methodologies (such as TDD, BDD, DDD, Agile, XP) and software - anything to do with testing goes here. (Formerly "The Testing Side of Development")

Moderator: General Moderators

User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

I've been considering that, but it seems like the Request is starting to spread too much and lose its focus.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

I admit that Request would grow and start doing things it shouldn't do.

Meaby that the Controller (or Action/Module) should setup a certain Context (which could have it's specific Registry) in which the database connections etc are available..
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Post by nielsene »

I think that's more what I'm growing towards. The "Context" holds the Registry (with associated DB's and PhraseBooks) along with Session data (which I do not consider part of the Request)
User avatar
nielsene
DevNet Resident
Posts: 1834
Joined: Fri Aug 16, 2002 8:57 am
Location: Watertown, MA

Re: Testing a Request

Post by nielsene »

McGruff wrote:
nielsene wrote:How do you normally test this? manually fiddle with $_GET/$_POST to get the data into them that the request needs? Assign into $_SERVER to change PHP_SELF or REQUEST_URI, etc?
Yes. You might want to save/restore superglobals in setup/teardown:

Code: Select all

function setUp() 
    {
        $this->_server_cache = $_SERVER;
        $_SERVER = array();
    }
    function tearDown() 
    {
        $_SERVER = $this->_server_cache;
    }
Setting $_SERVER to an empty array is the kind of thing you'd probably want to do to prevent test methods from interfering with each other. However, if you're running test groups, other test cases in the group might be using $_SERVER etc so it's best to restore them to their original state. I've been caught out like that before with a test which had to check the OS (from $_SERVER['SERVER_SOFTWARE']) but I'd wiped the $_SERVER array clean in another test case...
Coming back to this, for a bit:

Is this setUp/tearDown something you added to a custom subclass of UnitTestCase, that all your test cases descend from or do you just add it to the test cases when the test case needs?

I'm finding that I'm needing to add it to more and more of my test cases, so I think I should push it down to an generic subclass... I'ld have to remember to chain setUps/tearDown if the most specific class also has one, but .....
McGruff
DevNet Master
Posts: 2893
Joined: Thu Jan 30, 2003 8:26 pm
Location: Glasgow, Scotland

Post by McGruff »

In a test case I'd put up with more duplication than I normally would. Partly because it's less important for the test cases to be "perfect" code, maybe because resolving it makes the test case slightly less readable, or maybe just because I'm too dim to figure out a neat way to fix it :)

Inheritance hierarchies can get awkward but yes at some point I'd be thinking about extending UnitTestCase - exactly when is up to you. You could even tweak the code so that setUp/tearDown accept optional "save/restore" parameters.

What would be an alternative to inheritance? I suppose you could load a small, configurable controller-type object in setUp/tearDown that can do whatever you tell it to (aggregation replacing inheritance). I'd have to be having real problems to consider trying that though - not something I've ever done.
Post Reply