151–160 of 178 posts
I would make an exception for SQLite. Here's how you do it: - Write your schema so it's compatible with SQLite and your production DB, such as PostgreSQL. - When you're running tests, use SQLite instead of Postgres to run those tests. - Use SQLite in production. Go ahead, do it. You don't need Postgres, SQLite is fine. I promise. Trust me
Earlier quoted context omitted.
> Why not delete your test methods too and just test in production? This, but unironically. Depending on your use case, any local tests, whether mocked or using a swarm of local containers attempting to represent production may be a far stretch from production reality. Put everything behind feature flags and test your contracts, then release to production regularly and test against live data and live services.
You don't test in production. By definition, prod is what you care about and don't want to break. This is what preprod is for: an environment that stores, receives and processes the same data as prod. It replicates prod as closely as possible and errors or unexpected differences are investigated. Then there are rolling deployments in prod... [and you don't need containers at all]
Basically, preprod and any not-prod environments cannot ultimately perfectly reproduce prod, and in a sufficiently complex system, the failure states cannot be predicted in a replicated environment. Instead, using strategies like rolling deployments, you can test on the actual environment you want to validate.
If set up properly, it doesn't really risk breaking prod.
True "unit" tests are: * faster to run * give you less confidence in the correctness of the system (per time spent writing them) * when they fail, give you more information about where the failure is The more integration-y/e2e-y a test is, the more it strays from this: slower to run, more confidence that the system is correct, less info about where the failures are. I think people have learned to undervalue the prope…
Whenever/wherever there is piece of code that can tested as part of a unit test, write a simple test or two for it.
However, each time I run into 200 lines of setup code that will make the test pass trivially, I think an opportunity to simplify something was missed.
> QA says: “it doesn’t work”. Dev says: “it must be working, all the tests pass”. I've never experienced this, and I'm kind of doubtful this is a true reaction. I guess maybe it could happen in a team that is totally dysfunctional, where there's zero trust between QA and developers .. but in that case mocks are not the problem. The realistic reaction is "huh, guess we are missing some test cases".
Yup, the very next question here should be: Show me the failing/in correct behavior.
This means: * There's a case the automated tests don't cover. * There's a misunderstood requirement on the QA or Dev side. * There's a broken machine or configuration in a deployment.
Earlier quoted context omitted.
> The only thing you achieve with unit tests is to prove that you are still bug for bug compatible when changing your code. If your tests are ensuring buggy behavior, then... you're writing your tests wrong? What are you even trying to say with this? I've never once seen a unit test intended to enforce a bug...?
If you have a web API that returns a 200 OK with a JSON object with a missing entry when an item is not found, instead of a 404 error, then you have a bug in your API. But you cannot allow it to change because your users are relying on the existing behavior.
And you're using that... to justify that the "only" thing unit tests achieve is maintain bugs? Although in any case, this is no longer a bug, it's part of your spec now.
But regardless, what about the other 99%+ of unit tests that are enforcing correct behavior...?
Your argument is like saying that food is bad because people occasionally get food poisoning.
Earlier quoted context omitted.
what does unit testing have to do with whether or not you instrument the test with fake responses? those points of contact that you're mocking out at the perimeter, that data will sometimes need to reach a particular function through a collaborator...which you may want to mock? sometimes the dependency is not a third party, but it may be code that requires a ton of setup (as mentioned in article) that's not worth the…
I'm sorry, I did not intend to offend anyone obviously. Needless to say, this is just my opinion condensed in a sentence (therefore lacking a lot of context, which I should have provided). I was not aiming to define what a unit test is, more like when it stops being a unit test (which I thought it would be an easier agreement to reach than a definition of what is, but I guess I underestimated the task). My point was…
can it be a smell? maybe, that depends. Does it break your idea of single responsibility? maybe. Is it an integration test? not ... really because the test is primarily designed to verify the behavior of the rules of the function and not its interaction with a third party system.
so while you can argue that mocking is a smell in that context, that doesn't change the fact that it's still a unit test!
all that said, one can still make a case that the fundamental unit of work for a given context is not really a function, and so testing functions are actually integration tests! so I'll also grant that these definitions can be very context sensitive..