Recent submissions

Comment · 1 year ago
I think we're talking about the same thing :D? The service/business logic/whatever you might want to call it interacts with the storage via an interface - in prodcution that interface is implemented by a component that can talk to a real SQL database, in tests I can just create a wrapper around a hash map and use that.

EDIT: What I meant when I wrote that tests are not coupled to the underlying model/details is that with a mock you have to explicitly specify "when called with this return that". With an in memory database implementation you don't need to do anything, the code will just use the interface methods like "getX" or "saveY".

Comment · 1 year ago
I've had some good experience with a mix of those approaches, maybe not using mocks per se, but an "in-memory database implementation" (just a wrapper around the hash map that implements the same behaviors as a repository that deals with a real database) on one hand, and testcontainers on the other. (Still, using an in-memory db is way better than mocking, the tests are not coupled to the implementation details/the underlying model).

For simple use cases where I mostly just read/write from the database and don't expect any of those issues mentioned in the article (constraint violations or concurrency issues, because the application is quite simple tbh, plus I already have some testcontainers based integration tests for the components that deal with a real db and I reuse them) writing tests with an in-memory db implementation is quite nice - the setup is simple and running the whole test suite is instantaneous (literally something like 1-2s for a couple thousand tests, I don't need any framework for those kind of tests).

And on the other hand if I'm relying on something like an optimistic/pesimisstic lock or a framework feature, I will write a test with the real thing, using test containers. Also have a pretty good coverage with the components that deal with queues and databases specifically with testcontainers. And on top of that just a few e2e flows written using testcontainers as well.

Comment · 1 year ago
Comment · 1 year ago
It got updated, they have acknowledged there is a major outage.
Comment · 1 year ago
Yes, status page got updated: https://status.openai.com/. It says "This issue is caused by an upstream provider and we are currently monitoring."
Comment · 1 year ago
I might have misremembered that, but remember hearing the story. Now that I think about it I think that policy was applied only after unsuccessful CPR attempts.
Comment · 1 year ago
A friend's friend is a paramedic and as far as I remember they can take the rest of a day off after witnessing death on duty and there's an obligatory consulation with a mental healthcare specialist. From reading the article, it seems like those moderators are seeing horrific things almost constantly throughout the day.
Comment · 2 years ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton