@thomastospace Our use case is fairly valid, unless I am missing something super obvious. We have MySQL full text search via Scout, which has a migration for the full text table. Tests using sqlite choke on this. If I am not mistaken, there is little need to be testing a package from someone else, as in theory, the package maintainer has already done testing before releasing.
You have a service that uses something provided by Laravel Scout that can do the full-text search. You inject this in the constructor.
In your test, instead of injecting this service, make a mock of this service. Your class still thinks it's interacting with the class from Laravel Scout, but it's a fake object.
You then verify that your class sends the correct data to the mock service, and your mock service sends back a response to your class.
@thomastospace Fair point, I get confused with terminology sometimes. Which only adds to all the normal complexities in life :) The link to types of tests in sympfony is really great, thank you. From Laravel’s viewpoint, Feature tests are basically Integration tests if I read this correctly. This symfony makes the understanding of tests much more clear than anything else I’ve read or watched. Clear definitions really help.
@thomastospace and… AFAIK App::runningUnitTests works for all tests, not just Unit tests. Happy to be corrected on this as I am learning a lot from our conversation.
@thomastospace I do agree with the fear. And given time I am certain I will find a much better way to manage the issue at hand. I find I spend a considerable amount of time going back and rewriting my code to make it better. Tests are responsible for that. :)
Add comment