Page 2 of 2
Posted: Fri Aug 19, 2005 5:53 pm
by nielsene
I've been considering that, but it seems like the Request is starting to spread too much and lose its focus.
Posted: Fri Aug 19, 2005 6:11 pm
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..
Posted: Fri Aug 19, 2005 6:14 pm
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)
Re: Testing a Request
Posted: Sat Aug 27, 2005 9:35 pm
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 .....
Posted: Sun Aug 28, 2005 10:46 am
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.