integresql
localstripe
integresql | localstripe | |
---|---|---|
5 | 1 | |
711 | 188 | |
3.7% | - | |
8.9 | 6.4 | |
3 months ago | 5 months ago | |
Go | Python | |
MIT License | GNU General Public License v3.0 only |
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.
integresql
-
Mock unit test an API that uses postgres or integration test API with a "test" database?
For the case of PostgreSQL I've found IntegreSQL and its Javascript client really helpful because it can create a copy of the database per test case, which it helps to write integration tests with real DB calls.
-
Mocking database calls without a library?
Mocking has some advantages, but so does using a real database, at work we use https://github.com/allaboutapps/integresql and I quite like the approach that integresql has, since it makes possible to have a fresh database with your dummy data for every test without impacting the execution speed (compared to dropping an re-creating the database).
-
Ask HN: How do you test SQL?
Happy to hear that! When it comes to testing services that depend on PostgreSQL, this is still my preferred solution.
https://github.com/allaboutapps/integresql
disclaimer: author
- IntegreSQL – isolated PostgreSQL databases for integration tests
-
Pg_tmp – Run tests on an isolated, temporary PostgreSQL database
I haven't had a change to try it yet, but IntegreSQL[0] looks like this on steroids. It allows you to create a template (runs migrations and seed dates), and then uses Postgres's built in cloning functionality to maintain a pool of fresh databases. They claim 500ms to clone a database without the pool, and that the pool pretty much hides the latency entirely.
[0]: https://github.com/allaboutapps/integresql
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
What are some alternatives?
flyway-spawn-demo - CI demo using Flyway and Spawn
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.
otj-pg-embedded - Java embedded PostgreSQL component for testing
spawn-demo - Demo application to show how Spawn can be integrated in Development and CI
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
SS-Unit - A 100% T-SQL based unit testing framework for SQL Server