An excellent stepping down post, nothing more could be hoped for. Enjoy the next projects
Stepping down as Mockito maintainer after ten years
101–110 of 220 posts
Re: Stepping down as Mockito maintainer after ten years
#102Earlier quoted context omitted.
How do you substitute for dependencies that you're not testing, or that you want to deliberately break?
90% of the time (or more): you don't. The real thing is perfectly fine in a test with the right setup. Fileio is fast, I just need a test file in a tempdir. databases are fast, I just need an easy way to settup my schema. Sometimes I need the isolation but normally I do not.
Well, no - you don't.
What you're describing is a very limited subset of testing, which presumably is fine for the projects you work on, but that experience does not generalise well.
Integration testing is of course useful, but generally one would want to create unit tests for every part of the code, and by definition it's not a unit test if hits multiple parts of the code simultaneously.
Apart from that, databases and file access may be fast but they still take resources and time to spin up; beyond a certain project and team size, it's far cheaper to mock those things. With a mock you can also easily simulate failure cases, bad data, etc. - how do you test for file access issues, or the database server being offline?
Using mocks properly is a sign of a well-factored codebase.
Re: Stepping down as Mockito maintainer after ten years
#103Earlier quoted context omitted.
How do you substitute for dependencies that you're not testing, or that you want to deliberately break?
Why substitute dependencies? Is the isolation worth it?
For the same reason you isolate variables in a scientific experiment; to ensure you're controlling the test that you're running, and not accidentally testing something else.
To easily simulate failure cases, a range of possible inputs, bad data etc.
To make the testing process faster when you have hundreds or thousands of tests, running on multiple builds simultaneously across an organisation.
Off the top of my head :-)
Re: Stepping down as Mockito maintainer after ten years
#104Earlier quoted context omitted.
“The solution is to have dummy versions of services and interfaces that have minimal correct behavior” If you aren’t doing this with mocks then you’re doing mocks wrong.
I'd go a bit farther — "mock" is basically the name for those dummy versions. That said, there is a massive difference between writing mocks and using a mocking library like Mockito — just like there is a difference between using dependency injection and building your application around a DI framework.
> there is a massive difference between writing mocks and using a mocking library like Mockito
How to reconcile the differences in this discussion?
The comment at the root of the thread said "my experience with mocks is they were over-specified and lead to fragile services, even for fresh codebases. Using a 'fake' version of the service is better". The reply then said "if mocking doesn't provide a fake, it's not 'mocking'".
I'm wary of blanket sentiments like "if you ended up with a bad result, you weren't mocking". -- Is it the case that libraries like mockito are mostly used badly, but that correct use of them provides a good way of implementing robust 'fake services'?
Re: Stepping down as Mockito maintainer after ten years
#105Earlier quoted context omitted.
90% of the time (or more): you don't. The real thing is perfectly fine in a test with the right setup. Fileio is fast, I just need a test file in a tempdir. databases are fast, I just need an easy way to settup my schema. Sometimes I need the isolation but normally I do not.
I worked on a project where a dev wanted to mock out the database in tests "for performance, because the database is slow". I almost lost my shit. Even funnier, this was all hypothetical and yet taken as gospel. We hadn't even written the tests yet, so it was impossible to say whether they were slow or not. Nothing had been measured, no performance budget had been defined, no prototype of the supposedly slow tests ha…
> I almost lost my shit.
Hopefully one day you'll back at that, and realise what an immature attitude that was.
Re: Stepping down as Mockito maintainer after ten years
#106Earlier quoted context omitted.
I've found that most of the time that if you need to mock, you probably just need to do an integration test.
I can’t concur with this enough. I’ve been on projects where mocking _literally made the project less reliable_ because people ended up “testing” against mocks that didn’t accurately reflect the behavior of the real APIs. It left us with functionality that wasn’t actually tested and resulted in real bugs and regressions that shipped. Mocking is one of these weird programmer pop-culture memetic viruses that spread in…
> like Agile and OOP
Ha.
I think there's room to argue "Agile" is a popular bastardisation of what's meant by "agile software development", and with "OOP" we got the lame Java interpretation rather than the sophisticated Smalltalk interpretation. -- Or I might think that these ideas aren't that good if their poor imitations win out over the "proper" ideas.
With mocking.. I'm willing to be curious that there's some good/effective way of doing it. But the idea of "you're just testing that the compiler works" comes to mind.
Re: Stepping down as Mockito maintainer after ten years
#107> That's because starting JVM 22, the previous so-called "dynamic attachment of agents" is put behind a flag. Ok am I being stupid or is the pragmatic solution not to just to enable this flag for test runs etc. and leave it off in prod?
I think the problem is that it's on his users to enable this flag, not something that can be done by Mockito automatically.
Most people want their test suite to pass. If they ugprade java and mockito prints out a message that they need to enabled '--some-flag' while running tests they're just going to add that flag to surefire in their pom. Seems like quite a small speedbump.
Re: Stepping down as Mockito maintainer after ten years
#108Earlier quoted context omitted.
I'd go a bit farther — "mock" is basically the name for those dummy versions. That said, there is a massive difference between writing mocks and using a mocking library like Mockito — just like there is a difference between using dependency injection and building your application around a DI framework.
> there is a massive difference between writing mocks and using a mocking library like Mockito How to reconcile the differences in this discussion? The comment at the root of the thread said "my experience with mocks is they were over-specified and lead to fragile services, even for fresh codebases. Using a 'fake' version of the service is better". The reply then said "if mocking doesn't provide a fake, it's not 'moc…
In my opinion, we do mocking the exact opposite of how we should be doing it — Mocks shouldn't be written by the person writing tests, but rather by the people who implemented the service being mocked. It's exceedingly rare to see this pattern in the wild (and, frustratingly, I can't think of an example off the top of my head), but I know Ive had good experiences with cases of package `foo` offering a `foo-testing` package that offers mocks. Turns out that mocks are a lot more robust when they're built on top of the same internals as the production version, and doing it that way also obviates much of the need for general-purpose mocking libraries.
Re: Stepping down as Mockito maintainer after ten years
#109Earlier quoted context omitted.
I worked on a project where a dev wanted to mock out the database in tests "for performance, because the database is slow". I almost lost my shit. Even funnier, this was all hypothetical and yet taken as gospel. We hadn't even written the tests yet, so it was impossible to say whether they were slow or not. Nothing had been measured, no performance budget had been defined, no prototype of the supposedly slow tests ha…
> I almost lost my shit. Hopefully one day you'll back at that, and realise what an immature attitude that was.
I'm sorry you felt the need to post this in response to a figure of speech. Please keep your moralizing to yourself. Thank you.
Re: Stepping down as Mockito maintainer after ten years
#110Earlier quoted context omitted.
“The solution is to have dummy versions of services and interfaces that have minimal correct behavior” If you aren’t doing this with mocks then you’re doing mocks wrong.
In part, you’re right, but there’s a practical difference between mocking and a good dummy version of a service. Take DynamoDB local as an example: you can insert items and they persist, delete items, delete tables, etc. Or in the Ruby on Rails world, one often would use SQLite as a local database for tests even if using a different DB in production. Going further, there’s the whole test containers movement of having…
I use test containers and similar methods to test against a "real" db, but I also use mocks. For example to mock the response of a third party api, can't very well spin that up in a test container. Nother example is simply time stamps. Can't really test time related stuff without mocking a timestamp provider.
It is a hassle a lot of the time, but I see it as a necessary evil.