I was going through the list, nodding as I read all the reasons, agreeing with them all. But also thinking each time I’ll get one anyway. I guess I agree with the last sentence of the post haha. If anything, I’ll justify this by saying I want to choose with my money and encourage this further. But that’s really just to give me good conscience.
Readit Newsibizaman commented on Hypothesis: Property-Based Testing for Python hypothesis.readthedocs.io... · Posted by u/lwhsiao
My experience is that PBT tests are mostly hard in devising the generators, not in the testing itself.
Since it came up in another thread (yes, it's trivial), a function `add` is no easier or harder to test with examples than with PBT, here are some of the tests as both PBT-style and example-based style:
@given(st.integers())
def test_left_identity_pbt(a):
assert add(a, 0) == a
def test_left_identity():
assert add(10, 0) == 10
@given(st.integers(), st.integers())
def test_commutative(a, b):
assert add(a, b) == add(b, a)
@parametrize("a,b", examples)
def test_commutative():
assert add(a, b) == add(b, a)
Other things become much simpler, or at least simpler to test comprehensively, like stateful and end-to-end tests (assuming you have a way to programmatically control your system). Real-world, I used Hypothesis to drive an application by sending a series of commands/queries and seeing how it behaved. There are so many possible sequences that manually developing a useful set of end-to-end tests is non-trivial. However, with Hypothesis it just generated sequences of interactions for me and found errors in the system. After each command (which may or may not change the application state) it issued queries in the invariant checks and verified the results against the model. Like with example-based testing, these can be turned into hard-coded examples in your regression test suite.
For sure, the hardest part is to create meaningful generators for the problem at hand which can test interesting cases in a finite amount of time. That’s where the combinatory explosion takes place in my experience.
I wanted to highlight one unexpected but very welcomed side effect of having those stateful property tests is we could use them to design high fidelity stubs. I wrote a follow-up blog post about it https://blog.tiserbox.com/posts/2024-07-08-make-good-stubs-w...
ibizaman commented on Hypothesis: Property-Based Testing for Python hypothesis.readthedocs.io... · Posted by u/lwhsiao
> Property based testing involves defining the conditiosn and properties, writing code that generates the conditions and for each property writing a bit of code that can refute it by passing if and only if it is true of the subject under test for a particular set of inputs.
You're downplaying the amount of code required to properly setup a property-based test. In the linked article, the author implemented a state machine to accurately model the SUT. While this is not the most complex of systems, it is far from trivial, and certainly not a "bit of code". In my many years of example-based unit/integration/E2E testing, I've never had to implement something like that. The author admits that the team was reluctant to adopt PBT partly because of the amount of code.
This isn't to say that example-based tests are simple. There can be a lot of setup, mocking, stubbing, and helper code to support the test, but this is usually a smell that something is not right. Whereas with PBT it seems inevitable in some situations.
But then again, I can see how such tests can be invaluable, very difficult and likely more complex to implement otherwise. So, as with many things, it's a tradeoff. I think PBT doesn't replace EBT, nor vice-versa, but they complement eachother.
You’re right it’s always a trade off. One unexpected but very welcomed side effect of having those stateful property tests is we could use them to design high fidelity stubs. I wrote a follow-up blog post about it https://blog.tiserbox.com/posts/2024-07-08-make-good-stubs-w...
ibizaman commented on Hypothesis: Property-Based Testing for Python hypothesis.readthedocs.io... · Posted by u/lwhsiao
Property based testing is fantastic.
Why is it not more popular?
My theory is that only code written in functional languages has complex properties you can actually test.
In imperative programs, you might have a few utils that are appropriate for property testing - things like to_title_case(str) - but the bulk of program logic can only be tested imperatively with extensive mocking.
I actually used property testing very successfully to test a DB driver and a migration to another DB driver in Go. I wrote up about it here https://blog.tiserbox.com/posts/2024-02-27-stateful-property...
I help privacy and data sovereignty enthusiasts take back control of their data without needing to change their habits.
I’ve been working for the past 3 years on SelfHostBlocks https://github.com/ibizaman/selfhostblocks, making self-hosting a viable and convenient alternative to the cloud for non technical people.
It is based on NixOS and provides a hand-picked groupware stack: user-facing there is Vaultwarden and Nextcloud (and a bunch more but those 2 are the most important IMO for non technical people as it covers most of one’s important data) and on the backend Authelia, LLDAP, Nginx, PostgreSQL, Prometheus, Grafana and some more. My know-how is in how to configure all this so they play nice together and to have backups, SSO, LDAP, reverse proxy, etc. integration. I’m using it daily as the house server, I’m my first customer after all. And beginning of 2025 it passed my own internal checkpoint to be shared with others and there’s a handful of technical users using it.
My goal is to work on this full time. I started a company to provide a white glove installation, configuration and maintenance of a server with SelfHostBlocks. Everything I’ll be doing will always be open source, same as the whole stack and the server is DIY and repair friendly. The continuous maintenance is provided with a subscription which includes customer support and training on the software stack as needed.
ibizaman commented on Niri – A scrollable-tiling Wayland compositor github.com/YaLTeR/niri... · Posted by u/atlintots
The only thing I feel like is missing from niri is a scratch layer. There are some apps that just don’t need to be tiled and it’s nice to have access to them immediately no matter “where” you are. Perfect example is matrix client. If the wife texts me I want to become able to pop that sucker up immediately and reply, not find the “matrix client workspace”. Plus it’s tiny and doesn’t need to be tiled. Same with media players.
Paperwm on gnome has this.
Would this scratch your itch? https://github.com/probeldev/niri-float-sticky
I didn’t try it myself though. I found it while scrolling https://github.com/Vortriz/awesome-niri
ibizaman commented on Using Emacs Org-Mode With Databases: A getting-started guide gitlab.com/ryanprior/emac... · Posted by u/adityaathalye
I used a similar setup a long while ago and wanted a way to connect to databases easily. So I wrote some code to parse the MySQL and Postres config files to extract database info in Emacs: https://stackoverflow.com/a/46114944
ibizaman commented on SystemD Service Hardening roguesecurity.dev/blog/sy... · Posted by u/todsacerdoti
Nice tip on debugging syscall issues!
That seems to be the takeaway.
Centralization of just about anything is an issue, not just messaging.
However, users still want/need the kinds of advantages that we get from monopolies/centralization, and implementing them in distributed systems is really hard.