@phpandcigars Nothing wrong with mocks. To use a test database you likely need to change your app so that what database you use is configurable at run time
@grmpyprogrammer There is a lot wrong with mocks! The fact alone that you need to know about implementation details at the time of writing a test makes me bang my head against the table.
@phpandcigars I am also curious about how you are writing unit tests without understanding the dependencies being used and what their implementation details are
@grmpyprogrammer A simple example: I write a unit test for a handler that saves data and returns a JSON with possible validation errors.
At the time of writing the test I don’t want to know if an entity manager, or a pdo or whatever method is used to store the data. I just want to know if I get the expected result and if the data is stored as expected.
I don’t need and want to know about the implementation details.
@phpandcigars You and I write tests and code very differently, which is okay. I see a handler that clearly has a dependency on something that saves data and I am not a fan of hand-waving where that dependency will come from.
@grmpyprogrammer Some unit tests tends to lock-in the implementation making refactoring difficult.
Personally, I only substitute infrastructure classes with in memory implementations in my tests instead of mocks for brevity and to facilitate refactoring with some success, but I still have to manually inject dependencies in the setUp phase, which can be tedious in some cases. I haven't found a solution to that issue appart from using a service container which can seriously hurt performances.
@nanimal There really is no difference between “mocks” and “in-memory implementations” — you are using a double and somewhat coupling things. Dealing with coupling always struck me personally as developers complaining about work. And in terms of “performance”, my own experiences with test suites lead me to believe that it doesn’t matter until you have test suites that take 30-40 minutes to run, which then becomes a nice-to-have problem with different solutions to mitigate the impact.
@grmpyprogrammer well the difference that I make between fakes and mocks is that the former is a working implementation of an interface managing an in memory state and the latter is a pre-programmed object returning a fixed response given an expected input. I found fakes to be more reliable than mocks which can make test quite verbose and sometimes unreliable. I do not mind the work personally but it's always a struggle to make tests expressive and to the point.
@m1ke I ask because it is very likely that many of those integration tests could become unit tests with doubles that return real data collected from production instead of calling databases and 3rd party services. I would definitely make the case that a test suite that takes an hour to run to be slowing down the ability to deploy changes
@grmpyprogrammer Here's something that's been frustrating me this week: how best to unit test static methods that call other static methods that talk to the database?
I ended up sidestepping the issue by adding some testable logic to a repository class that allowed me to mock things (using a combibation of actual mocks as well as anonymous classes to override static methods). Are there other ways to capture a static method call & return what I want to test?
@grmpyprogrammer well, yes, and that's in progress (big codebase, takes time), just hoping there was a quick workaround that is lesser-known but a good stopgap...
Using anonymous classes has been the best tool so far for bridging the gap.
@grmpyprogrammer@kboyd that’s what we are using. Note that it hasn’t been touched since feb 22, and the supported php version list stops at 7.4. We’ve had some issues around the reflection code and modern php 8 syntax for constructors.
@sephster@grmpyprogrammer@kboyd honestly I don’t know that we have. Iirc we’re on 3.x still, and when we tried to move to 4.x hit other problems (which are logged as issues from others), but the stated support stopping at 7.4 and the documented issues with 8.x functionality and the other random documented regression issues with 4.x and some of the open questions in the issues being open for so long…. Yeah, just didn’t seem worth it.
@kboyd I hope I won't be boring too much with codeception, but it's a life saver when it's too risky to do major reflectors. You can set browser tests up, but also unit tests that will work against your test db, and it's then possible to just call your static methods, letting them do the real work.
It's awful from a certain standpoint, but also a good tradeoff from another one. What grumpy said is of course the best way to do it.
@thgs Both are hard to do. Convincing people to do extra work with no immediate benefit is even harder. The easiest argument for why they are needed is “because it allows us to build new things instead of constantly fixing old things”
@thgs@grmpyprogrammer I mean in Laravel you have a lot of work done magically for you. Like resetting the database to the state it had before the test ran.
What if for non-technical reasons you can not use Laravel and what to setup something similar manually. How would you proceed?
Ah yes, that is why I do not like laravel that much anymore. I figured out that if laravel does the magic there is not much space for me to do the magic!
@grmpyprogrammer when encountering a code base lacking any tests of any kind, what’s the fastest and most effective way to get started with testing to start gaining a sense of confidence?
@sarah if unit tests are impossible to write (which is almost an absolute rule in the beginning with such projects), you can set some end-to-end (browser) tests up with e.g. codeception, and then start refactoring the code that those tests cover. Start with the ones that are the essential for the app to work, then core business logic etc.
It takes time to prepare the grounds, but in the long run you will thank yourself many, many times.
@grmpyprogrammer I'm currently struggling to get phpstan working inside a Github action. My code uses an extension which is challenging to install but phpstan barfs because it can't discover the symbols. I'm currently writing code to generate a stub for the extension but it seems non-optimal!
@gbxyz I’ll let @grmpyprogrammer answer but I’ve had this struggle in the past. Have you considered using docker containers with the extension and stan installed?
Add comment