localstripe
otj-pg-embedded
localstripe | otj-pg-embedded | |
---|---|---|
1 | 6 | |
189 | 669 | |
- | 0.6% | |
6.4 | 6.5 | |
6 months ago | about 1 month ago | |
Python | Java | |
GNU General Public License v3.0 only | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
localstripe
-
Pg_tmp – Run tests on an isolated, temporary PostgreSQL database
Anyway, I won't go as far as saying that mocks are useful, sometimes a mock is the easiest and best way -- but I can say that I spend most of my time writing E2E tests, and I trust them a lot and they give me trust in my codebase much more than mocks or unit tests do. I barely write unit tests anymore to check edge cases, because if I really cared I'd just generate them -- and I don't really have to care because I use strong type systems where possible (Typescript for JS, I avoid PHP/Python/Ruby, Rust, Haskell).
Here comes the hot-take -- unit tests (and their rise in popularity/necessity) is actually a direct reflection of the adoption of non-compile-time-type-checked dynamically interpreted languages, and burdensome class-based "type systems". Correct usage of good, expressive and concise (where possible) type systems encourages you to make invalid/nonsensical states impossible, and people got excited about how fast you could churn out code (compared to Java most things feel pretty productive) and they started having numbers where they thought they had strings, and negative numbers where they thought they had natural numbers. Good type systems make it easy to make these cases impossible. As for the business stuff (never store decimals for currency, make sure your amounts are natural numbers, etc), you have to learn that with time/intuition built over time -- you don't know to write that unit test unless it's bit you before (though sitting down to write unit tests might tease it out of you).
I write unit tests as regression tests basically now, but I find I rarely have to do that, since most of the time when a weird case has gone through it's an indicator that I was too lose with the types.
[0]: https://github.com/adrienverge/localstripe
otj-pg-embedded
-
Testcontainers
Anyone have an opinion of embedded-postgres vs https://github.com/opentable/otj-pg-embedded (of which its a fork) for Clojure use?
-
What's the best approach for creating an embedded Postgresql to be used in production?
Can you elaborate a bit on this part? I'm still unsure why it's unadvised to do this, as I understood from other commenters it's because there is no official support for it correct? Why can't I use opentable for instance? https://github.com/opentable/otj-pg-embedded
-
SQLite Is Dynamically Typed (2020)
It's pretty easy to run embedded postgres on the JVM: https://github.com/opentable/otj-pg-embedded
The defaults create a temporary DB which is useful for dev & tests, but a pair of calls to .setCleanDataDirectory(false) and .setDataDirectory("...") will change that.
If you don't like the default postgres version, you may select one from https://search.maven.org/search?q=io.zonky.test.postgres or include your own postgres binary.
- Experiment: using PostgreSQL as a user process
-
Pg_tmp – Run tests on an isolated, temporary PostgreSQL database
I've been using this embedded PostgreSQL thing for tests:
https://github.com/opentable/otj-pg-embedded
It's very simple to use and works perfectly. The one problem, and it's a significant one, is that it only ships one version of PostgreSQL, and adding another was difficult enough that I didn't.
What are some alternatives?
testcontainers-go - Testcontainers for Go is a Go package that makes it simple to create and clean up container-based dependencies for automated integration/smoke tests. The clean, easy-to-use API enables developers to programmatically define containers that should be run as part of a test and clean up those resources when the test is done.
integresql - IntegreSQL manages isolated PostgreSQL databases for your integration tests.
Testcontainers - Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.
flyway-spawn-demo - CI demo using Flyway and Spawn
postgresql-embedded - Embedded PostgreSQL Server
rush - Production-driven prototyping. This starter is setup in a production-friendly way and will setup tests + dev environment exactly like a live project will work. Works the same both on your laptop or Github CI, so you can go from hacking on your laptop to a full gitops environment.
entr - Run arbitrary commands when files change
embedded-postgres - Run a real Postgres database locally on Linux, OSX or Windows as part of another Go application or test