That's why I prefer test frameworks that make parametrised tests so easy that they become the default.

Kotest and Spock are such frameworks.

>The first test of a class of tests is the hardest, but it's almost always worth adding.

Agreed, this has been my experience too.

The pyramid makes sense for certain types of application - very logic heavy with light integration touch points with everything cleanly dependency injected. rqlite fits this pattern.

If you're building a logic lite application which has a lot of integration touch points (I find most commercial code actually fits this pattern) then it makes zero sense - an integration test heavy test suite is what you want - an upside down pyramid if you will.

If you have a ball of mud on your hands then it doesnt matter what kind of app it is, E2E tests are the only thing that makes sense and you need to build very sophisticated fakes (requiring a lot of engineering skill) to avoid things like flakiness bugs and the token scraping problem you referred to.

If you're writing a parser, you probably want 100% unit tests and property tests for all those millions of parser edge cases. No pyramid of any shape is required, just a slab.

The testing pyramid reminds me of microservices: the people who came up with Their Grand Idea had no clue what it was about their specific circumstances that made their approach work for them but still managed to market it as The Way.

Realistically, the ultimate shape of your test suite should be an emergent property based upon a series of smart, local decisions - ideally TDD'ed tests which match the kind of code you are writing right now. Making a particular shape a goal is asinine.

Thanks for flagging -- fixed.

It's not done by Aphyr himself, but someone ran Jepsen-like testing a couple of years back.

https://github.com/wildarch/jepsen.rqlite/blob/main/doc/blog...

Could you elaborate on what kind of project you're using rqlite for?

Yes, Replicated for example: https://www.replicated.com/blog/app-manager-with-rqlite

It's still in active use by them. https://www.textgroove.com/ is another company that uses it, though I know less about their use case.

Yes, it's our backing database for Morio [1], an open source observability plumbing tool.

We're still building it but we're dogfooding it and run it in production ourselves.

Can't recommend it enough

[1] https://morio.it/

I have been using it in production for more than a year. There were some early hiccups associated with my use-case that were resolved on upgrade and with a bit of tuning. Otherwise it has been very stable. I'll say that I wish the official language bindings were tested more like rqlited itself. They've been more problematic than the database.

rqlite supports a few levels security, which you can use separately or together.

You can enable BasicAuth on the HTTP endpoints. You can also require that any client presenting BasicAuth credentials has the right permission for the operation the client is trying to perform. Finally you can also enable Mutual TLS, requiring that any client that connects must first present a cert that is signed by an acceptable CA.

For full details on security check out https://rqlite.io/docs/guides/security/

Yes, that is right. So here's my disclaimer: I'm the author of rqlite.

I really admire the testing that the SQLite team does[1], and the way it allows them to stand behind the statements they make about quality. It's inspiring.

IMO there have only been two really big improvements to software development relative to when I started programming professionally 25 years ago: 1) code reviews becoming mainstream, and 2) unit testing. (Perhaps Gen AI will be the third). I believe extensive testing is the only reason that rqlite continues to be developed to this day. It's not just that it helps keep the quality high, it's a key design guide. If a new module cannot be unit tested during development, in a straightforward manner, it's a strong sign one's decomposition of the problem is wrong.

[1] https://www.sqlite.org/testing.html

Probably a lot better than 99.999% of software? This is made by one person, with code that cannot be deterministically tested (external SQLite) But you seem to be cargo culting, as this testing has existed in DBs for nearly a decade

FYI this is a reference to Deterministic Simulation Testing (DST), which certainly sounds interesting: https://apple.github.io/foundationdb/testing.html

Making good on the username, for sure!

This is HN outrage bait if I've ever seen it

> Why Go? Go is garbage collected, how is this even a good idea for a database engine in the first place?

First, the database itself is Sqlite, which is C and arguably the most widely deployed database engine in the galaxy.

Secondly, Go is popular for network services as it's easy to write (relative to languages like C++, Rust etc), is memory-safe and is "fast enough" for the network/disk to be your bottleneck and its concurrency features make it easy to use hardware efficiently without having to worry about scheduling in your application, among other reasons.