localstripe
rush
localstripe | rush | |
---|---|---|
1 | 1 | |
189 | 3 | |
- | - | |
6.4 | 0.0 | |
6 months ago | over 2 years ago | |
Python | Python | |
GNU General Public License v3.0 only | MIT License |
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
rush
-
Pg_tmp – Run tests on an isolated, temporary PostgreSQL database
for python - i have a fully setup template that creates a scratch postgresql db, loads the schema and then tears it down.
its pre-integrated with Black, types, etc
https://github.com/RedCarpetUp/rush
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.
otj-pg-embedded - Java embedded PostgreSQL component for testing
flyway-spawn-demo - CI demo using Flyway and Spawn
integresql - IntegreSQL manages isolated PostgreSQL databases for your integration tests.
entr - Run arbitrary commands when files change
spawn-demo - Demo application to show how Spawn can be integrated in Development and CI