Skip to content

[9.x] Handle requests in test (rather than separate server process) #1170

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

inxilpro
Copy link
Contributor

@inxilpro inxilpro commented Apr 8, 2025

Right now, Dusk makes requests to a separate server process. This has a few downsides:

  1. Test setup needs to run via special _dusk/ routes rather than using normal factories/setup
  2. Special .env.dusk handling is necessary
  3. Certain testing affordances, like RefreshDatabase, aren't available
  4. Dusk tests need, generally, to be treated differently from other tests

This proof-of-concept adds an HTTP server and custom web driver implementation that lets us handle the entire Dusk lifecycle inside our test process. This allows us to treat incoming browser requests as though they were the same as $this->get(...) or $this->post(...) right in the test case.

Considerations

For the most part, this is a pretty minimal change for the impact it could have. That said, there are a few things to consider:

  1. Right now I'm essentially translating https://demo-app.test/profile into http://localhost:8099/profile. This doesn't account for things like domain-routing. Probably the easiest solution is to just pass the entire request as a query string, so something like http://localhost:8099/?url=https://demo-app.test/profile. This shouldn't be that hard, but might need some further thought.
  2. There's a bunch of code that could/should be removed. Things like Laravel\Dusk\Http\Controllers\UserController which is no longer necessary with this approach, and the logic around .env.dusk that is also not necessary. Before I go ahead and make the diff that much larger, I'd like a little bit of community/maintainer feedback.
  3. Overall, this is changing how Dusk works pretty significantly. That said, it should be fairly backwards compatible, and I think the upside is well worth it, but I get it if there's not appetite to introduce a big breaking change.

If anyone out there has a big Dusk testsuite that they want to try this with, I'd love some real-world feedback!

How to test

If you don't have repositories key in your composer.json file, add one, and then add my fork to it.

"repositories": [
  {
    "type": "vcs",
    "url": "https://github.com/inxilpro/laravel-dusk-fork"
  }
]

Then, install my branch:

composer require laravel/dusk:dev-proxy-requests --dev

Finally, if you DuskTestCase implements the driver() method, you need to swap Facebook\WebDriver\Remote\RemoteWebDriver for Laravel\Dusk\Driver\AsyncWebDriver.

Copy link

github-actions bot commented Apr 8, 2025

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

@JayBizzle
Copy link
Contributor

This would take Dusk to the next level in my opinion. Being able to assert things like in normal tests (Mailables, Events, Jobs etc) would be game changing for us.

Are there any performance improvements by running the tests via this method?

I was hoping to install this to test against our quite large Dusk test suite, but I am in some kind of composer dependency hell

Problem 1
    - Root composer.json requires laravel/dusk dev-proxy-requests -> satisfiable by laravel/dusk[dev-proxy-requests].
    - laravel/dusk dev-proxy-requests requires react/http ^1.10 -> satisfiable by react/http[v1.10.0, v1.11.0].
    - react/http[v1.10.0, ..., v1.11.0] require psr/http-message ^1.0 -> found psr/http-message[1.0, 1.0.1, 1.1] but the package is fixed to 2.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

@inxilpro
Copy link
Contributor Author

@JayBizzle what happens if you try:

composer require laravel/dusk:dev-proxy-requests --dev -W

@JayBizzle
Copy link
Contributor

Thanks for trying to help, dont want to derail this PR with technical support, I think i have other packages conflicting. Been down the ChatGPT route trying to fix this, but to no avail

composer require laravel/dusk:dev-proxy-requests --dev -W
./composer.json has been updated
Running composer update laravel/dusk --with-all-dependencies
Loading composer repositories with package information
Updating dependencies                                 
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires laravel/dusk dev-proxy-requests -> satisfiable by laravel/dusk[dev-proxy-requests].
    - laravel/dusk dev-proxy-requests requires react/http ^1.10 -> satisfiable by react/http[v1.10.0, v1.11.0].
    - react/http[v1.10.0, ..., v1.11.0] require psr/http-message ^1.0 -> found psr/http-message[1.0, 1.0.1, 1.1] but these were not loaded, likely because it conflicts with another require.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants