#1113: Testing Framework Limitations
---------------------+------------------------------------------------------
Reporter: jake | Owner: felix
Type: defect | Status: new
Priority: high | Milestone: 1.0.2
Component: testing | Version: 1.0.1
Severity: normal | Keywords:
Has_patch: 0 |
---------------------+------------------------------------------------------
I have been diving into the testing code today and have found some issues.
I think the first one may warrant a high but the second one is just a
preference. I can commit code for both if that works for people.
First, several assertions in the !AgaviViewTestCase are broken. In fact,
nearly all the assertions that do anything with the response object share
the same problem. The only time that the response object sets up the
appropriate http headers is when the send method is called on the response
object. This happens in the controllers dispatch method, which is never
called. So, methods that are broken include:
* assertResponseHasContentType
* assertResponseHasHeader
* assertResponseHasCookie - Depending on whether view sets cookie
There may be others. I'm not sure what the 'right' way to fix this is. For
now I have extended the !AgaviViewTestCase and overridden runView with the
following changes:
* Second parameter specifies a method (read, write, etc)
* dispatch the controller with send_response set to true
* Wrap the dispatch in an ob_start/ob_end_clean so we don't get output
* Call setResponse on the container with the return from the controller
This works for my purposes.
Second, the test framework requires that all test code exist under one top
level test directory. This prevents you from creating a layout such as:
{{{
app/modules/Default/tests/actions/LoginActionTest.php
}}}
Instead you are restricted to using something like:
{{{
app/tests/Default/actions/LoginActionTest.php
}}}
Although this is how PHPUnit recommend the setup I don't think it should
be enforced as a requirement. My suggestion would be to do one of the
following.
1. Change line 108 in {{{AgaviTesting.class.php}}} such that it doesn't
require a prefix. At least at a minimum, in this case, you can specify the
full path to your tests in the {{{suites.xml}}} file.
2. Add an optional module attribute to the suite or testfiles element. If
specified, the testfile becomes
{{{%core.module_dir%/%config.module_name%/tests/%testfile%}}}. I prefer
this greatly.
--
Ticket URL: <http://trac.agavi.org/ticket/1113>
Agavi <http://www.agavi.org/>
An MVC Framework for PHP5
_______________________________________________
Agavi Tickets Mailing List
[email protected]
http://lists.agavi.org/mailman/listinfo/tickets
