localstripe
flyway-spawn-demo
localstripe | flyway-spawn-demo | |
---|---|---|
1 | 14 | |
189 | 5 | |
- | - | |
6.4 | 0.0 | |
6 months ago | about 1 year ago | |
Python | PLpgSQL | |
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
flyway-spawn-demo
- Deploying data across environments
- Looking for opinions on spinning up dev/staging environment databases.
-
Creating a Basic CI/CD Pipeline
I used to run databases as containers but then had to manage data seeding as well. Checkout a very handy tool called Spawn
- Database for every PR
- Ephemeral... data?
- Database Image as a service. What do you think?
-
How to get realistic datasets into GitHub codespaces?
Over at Spawn we've been really excited to see the rise of GitHub Codespaces. We're looking forward to hearing about all the exciting improvements that have been made to development processes as a result (like GitHub's own engineering team's improvements!).
-
Going all-in on cloud-based development with realistic databases
Over at Spawn we've been really excited to see the growth of Gitpod. We put together this article discussing remote development through 2020 and 2021 and how cloud-based development environments are an excellent alternative to consider over other options.
- Show HN: Spawn – Throwaway Databases for CI and Development
-
Development databases in Docker aren’t good enough
We've explored migration issues and how running schema migration tests in CI can help in this repo: https://github.com/red-gate/flyway-spawn-demo
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.
otj-pg-embedded - Java embedded PostgreSQL component for testing
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
django-blog
chazapp