7 Comments

  1. Alex

    Hey, great post! I’ve been pulling my hair out trying to determine the problem for a while now. So in the end, did you find any alternative solutions? Insofar as I can see, testing is practically impossible without intervention into your codebase each time or using Laravel Dusk instead, which obviously takes substantially more time to execute. Any other ways?

    • Alex

      Btw Option 1 is not a tenable solution, as it might lead to subtle bugs. For example, referencing the $errors variable in your views requires that your ShareErrorsFromSession middleware is active; if it’s off, it might take you quite some time to figure out what went wrong. Same for any other middleware on which your app depends implicitly.

    • munderwood

      In the end I switched to the practice of manually writing a test for each English route, with the idea that any accidental (or simply poorly thought through) changes to the routes file would end up causing a test to fail, instead of having the tests automatically change themselves to match, and then still passing. My goal was to set the project up from the start to be easily translatable later, but for the foreseeable future it’s only going to exist in English anyway, so I had to move on to other parts. I haven’t really thought much more about this issue since then, but I’d certainly be interested in knowing about it if you came up with a better option for the automated approach!

      As for your point about the first option, I agree that disabling all middleware during testing could lead to a slew of issues. But I just meant that you could choose not to use the LaravelLocalizationRedirectFilter middleware in your application. This would lead to having the routes /about and /en/about both work and both show the same thing, instead of having /about issue a redirect to /en/about. But I don’t think it would cause any of the other problems you mention, would it?

      • Alex

        So I guess you went with setting ‘hideDefaultLocaleInURL’ to true then, eh? This way the routes for your default locale (‘en’) become non-localized, and you can at least test those. I did precisely that and was able to manipulate app locale with some configuration in phpunit.xml. However, the old problem remains, because there’s no way to test localized routes with any prefix other than ‘en’ — you either get 302 or 404. I did notice though that mcamara had a few tests in his package, but I found them difficult to understand.

  2. I’m running into the same error, unfortunately. I definitely felt that your first option was sub-optimal and tried the second one. Well, it worked for the English language version of my site, but did not work for anything other than the landing page.

    Now that we’re a few months down the road, were you able to solve this in the end?

    Thanks for your post :)

  3. I figured out what the problem was. I had multiple .htaccess files on my shared server. Apparently they were interfering with each other.

    I have now cleared out my files and will start again tomorrow. I think it should work then :)

    • munderwood

      Glad you got things (hopefully) sorted!

      As I mentioned above, in the end I abandoned the idea of automatically verifying only the routes in the routes file, and instead coded a test for each route so that tests would start failing if breaking changes were made to the routes file…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.