How do I run Codeception functional tests against a simple custom frameworkless web application? (that implements PSR-15 RequestHanlderInterface) #6058
Unanswered
githubeing
asked this question in
Q&A
Replies: 1 comment
-
Please see my comments at https://stackoverflow.com/q/65393662/366348 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Assume the following simple web app:
One can easily run it by placing the following code in their web front-controller (e.g.
public_html/index.php
):Now, I'd like to run Codeception feature tests against it, written in Gherkin. Consider the following simple test:
To run acceptance tests against it, I have to provide my steps implementation. I'll reuse standard steps for that, provided by the Codeception:
But now, I want to use same tests code to run these same tests as functional tests using Codeception. For this, I have to enable the module that implements these same steps in functional way. Which one do I use? Codeception provides several, but they're for 3rd party frameworks, e.g. Laravel, Yii2, Symphony etc. What do I do for such a simple app that doesn't use any 3rd party framework?
Here's what I've managed to do. I've created my own
\Codeception\Lib\InnerBrowser
implementation that inherits from\Codeception\Module\PhpBrowser
provided by Codeception, in which I substitute the web client that Codeception uses (it uses Guzzle) with my own implementation (which also inherits from the Guzzle client) that doesn't perform any web requests but requests my app instead:In order for this to work, I have to make my app return Guzzle
Response
s (which implement PSR'sResponseInterface
as well) - because PhpBrowser expects its web client to return them - which is why I had to make theResponseFactory
a constructor parameter to be able to substitute it in tests.In such a configuration, everything seems to work fine.
But there's a problem. Notice the
App::handle()
signature:- it differs from the one that it implements, which is declared in
RequestHandlerInterface
:Technically, it's completely legal because it doesn't break the parameter contravariance required by the Liskov Substitution Principle.
The problem that I've faced is that
PhpBrowser
assumes that it sends a (client-side)RequestInterface
s (over the network) but my app requires a (server-side)ServerRequestInterface
instead, to be able to access parameters that are set on the server side such asServerRequestInterface::getParsedBody()
, session etc.How do I workaround this? Framework modules provided by Codeception already do this somehow... And BTW, haven't Codeception (or someone else) provided yet an easy way to run functional tests against custom code?
Here's
composer.json
BTW:Beta Was this translation helpful? Give feedback.
All reactions