41–50 of 85 posts
Does anyone know if there are libraries for writing fakes ? I wonder why there is a lot of mock libraries but I know none for writing fakes.
https://github.com/rr/rr
Can we not have articles like this with blanket statements like this please? As with everything in software, no one size fits all. Mocks have their place. There are situations when the only way we can test something out is to mock out a certain function call. Sometimes our dependencies are so complex and deep that we cannot just replace it with a fake. But with a little mock we can replace a function or a class withi…
I don't grasp the difference between a mock and a fake. Both are substitutes for an expensive or unavailable component. Maybe the fake is more dynamic than the mock? The point seems moot.
Fake is just a simple implementation, like in-memory db to stand-in for a real one. In the optimal case, provided by library authors.
There are entirely separate communities IMO when it comes to automated tests. There are the pushing-the-edge-of-excellence folks, constantly refining methods and approaches, who tend to be passionate about the holistic benefits of testing. And there are the folks who write convoluted tests that, when you dig into them, just confirm that String's .equals() works OK. DAO/database tests which have mocking going on to th…
It's all about staying in language though, at least in my opinion. The test suite I don't run is the one that requires the complicated docker compose stack and the local network to look just right. The test suite I do run is the one where I hit "run" in my IDE and then it lets be jump to what failed and debug seconds later. That, IMO, is what mocking is about: making the tests fast and easy to run so they actually ar…
I feel that if most of your tests relies on mocks it is a symptom of a very side-effected programming style. If you cannot unit test most your business logic then you are probably mixing up your business level code with side-effecting code (like calling APIs or DBs). Personally I've found it better to split pure business logic and side-effecting logic as close to the edge (API endpoint handler) as possible. Then it i…
> business level code with side-effecting code (like calling APIs or DBs). Sometimes the business logic is in DBs with stored procs.
There are entirely separate communities IMO when it comes to automated tests. There are the pushing-the-edge-of-excellence folks, constantly refining methods and approaches, who tend to be passionate about the holistic benefits of testing. And there are the folks who write convoluted tests that, when you dig into them, just confirm that String's .equals() works OK. DAO/database tests which have mocking going on to th…
Unit tests should validate error paths are properly exercised and that we handle expected results appropriately. It is wild how often this is not expressed in unit tests.
Does anyone know if there are libraries for writing fakes ? I wonder why there is a lot of mock libraries but I know none for writing fakes.
I've actually messed around with a library that makes stubs by recording external calls to things like APIs or databases. Sure, it can get a little brittle at times, but it's kind of cool because it's using real calls to create these stubs, and you don't have to put in a ton of extra work. Like anything else, it's about weighing the pros and cons and seeing what fits best for your project.
Does anyone know if there are libraries for writing fakes ? I wonder why there is a lot of mock libraries but I know none for writing fakes.
I think this one is context dependent. If you are a small or medium project that doesn't make many RPCs just test with the real thing. Once I got to google which makes many RPCs in every layer it just wasn't viable to not use mocking. I use mocks in almost every thing. Yes, it makes unit tests brittle and couples to implementation. But unit tests are cheap and often need to be changed anyways. It also allows you to h…
Do they still have guitar? I thought guitar was a really cool project
Can we not have articles like this with blanket statements like this please? As with everything in software, no one size fits all. Mocks have their place. There are situations when the only way we can test something out is to mock out a certain function call. Sometimes our dependencies are so complex and deep that we cannot just replace it with a fake. But with a little mock we can replace a function or a class withi…
Earlier quoted context omitted.
I don't grasp the difference between a mock and a fake. Both are substitutes for an expensive or unavailable component. Maybe the fake is more dynamic than the mock? The point seems moot.
Maybe more eloquently put: https://martinfowler.com/articles/mocksArentStubs.html