I agree with this in principle, but some things can only be mocked, like AWS interactions in a test/CI environment.
How to test without mocking
71–80 of 225 posts
Re: How to test without mocking
#72If you're writing a CRUD app and mocking your database calls instead of just starting an actual Postgres instance before running the tests, you're probably using mocking wrong. If you're writing a custom frontend for GitHub using the GitHub API and don't bother writing a decent set of mocks for how you expect the GitHub API to behave, your app will quickly require either full manual QA at best or become untestable at…
Clearly mocking DB is a footgun and it's not that hard to setup e2e test.
Use TestContainer or Docker on a random port, run your API on a random port.
Every tests seeds all the data needed to run (user, org, token), it requires an initial setup but then you just reuse it everywhere, and voila. No side effects, no mock to maintain, it also test your auth and permissions, almost 1:1 with prod.
Re: How to test without mocking
#73Sigh, no no no, no, no it's not.
In fact, Mocking is an essential tool for writing _unit_ tests; you know, testing exactly one thing (a 'unit') at a time. In Java for instance, a 'unit' would be a single static method, or a single class. Other languages will have different definitions of these terms, but the essential point would be "smallest reasonable grouping of code that can be executed, preferably deterministically"
The problem is people conflate the various levels of integration tests. You actually should* have both: Full unit test coverage + an integration test to prove all of the pieces work together successfully. Small unit tests with mocks will point you _very quickly_ to exactly where a problem is a codebase by pointing out the effects of contract changes. Large integration tests prove your product meets requirements, and also that individual components (often written by different teams) work together. They are two different things with two different goals.
* Important Caveat on the word 'should': Testing de-risks a build. However, if your business product is a risk itself (lets say you're hedging a startup on NFTs going wild), then your testing should reflect the amount of risk you're underwilling to spend money on. Unit testing in general speeds up development cycles, but takes time to develop. A good Software Engineering leader recognizes the risks in both the business side and development side and finds a balance. As a product matures, so should the thoroughness of it's testing.
Re: How to test without mocking
#74Bad article.
Some of the advice is good, like decoupling I/O and logic where that makes sense. But the general idea of mocking being an anti-pattern is overreach.
This kind of thinking is overly rigid/idealistic:
> And with Postgres you can easily copy a test database with a random name from a template for each test. So there is your easy setup.
> You need to test reality. Instead of mocking, invest in end-to-end (E2E) testing.
"Easily" is like "just." The ease or difficulty is relative to skill, time, team size, infrastructure, and so on.
As for testing reality, sure. But there's also a place for unit tests and partial integration tests.
In some situations, mocking makes sense. In others, full E2E testing is better. Sometimes both might make sense in the same project. Use the right tool for the job.
Re: How to test without mocking
#75If you're writing a CRUD app and mocking your database calls instead of just starting an actual Postgres instance before running the tests, you're probably using mocking wrong. If you're writing a custom frontend for GitHub using the GitHub API and don't bother writing a decent set of mocks for how you expect the GitHub API to behave, your app will quickly require either full manual QA at best or become untestable at…
[flagged]
Re: How to test without mocking
#76If you're writing a CRUD app and mocking your database calls instead of just starting an actual Postgres instance before running the tests, you're probably using mocking wrong. If you're writing a custom frontend for GitHub using the GitHub API and don't bother writing a decent set of mocks for how you expect the GitHub API to behave, your app will quickly require either full manual QA at best or become untestable at…
And if you have to mock, at least try to have somebody else write the mock. Testing your understanding of GitHub's API against your understanding of GitHub's API isn't useful. Testing your interpretation of the API behavior against somebody else's interpretation provides a lot more value, even if it isn't nearly as good as testing against the actual API.
Re: How to test without mocking
#77I've mocked a lot in my past. Last 2 years I've been using fakes explicitly, although it has an overhead, I like it as there is less maintenance and refactoring with tests.
Re: How to test without mocking
#78If I already have passing tests for anything function A might do, I can safely assume it will behave the same when called from B, C and D.
In some languages A might free a memory allocation e.g. after communicating with some server.
If B also frees that memory then there is a bug. Presumably this means B's tests are wrong/incomplete. If B was mocking A to avoid the IO, you might not find out.
Re: How to test without mocking
#79“Mocks only test the happy path.” This is a problem with the test authors, not mocks. “All the bugs are when talking to an actual database.” Databases have rules that need to be fillowed, and a lot of those can be tested very quickly with mocks. The combined system can have bugs, so don’t only use mocks. Mocks and unit tests are not a substitute for all the other tests you need to do. How this person can claim to be…
He probably meant it takes more effort to create mocks for all the negative cases. In most cases you won't have the time or the bandwidth to do this.
Try mocking DB triggers, views, access rules etc in mocks and you will know why most teams don't bother mocking but use the real thing instead.
And about the comment about him being a CTO. Well he is a CTO and you?
Re: How to test without mocking
#80Earlier quoted context omitted.
Re. postgres, this is actually something I have always struggled with, so would love to learn how others do it. I’ve only ever worked in very small teams, where we didn’t really have the resources to maintain nice developer experiences and testing infrastructure. Even just maintaining representative testing data to seed a test DB as schemas (rapidly) evolve has been hard. So how do you - operate this? Do you spin up…
> Do you spin up a new postgres DB for each unit test? Yes.
Isn't that rather slow - or do you mean for each run of unit-tests.