hynek

The fancy word for that is Vertical Slice Architecture btw and it's the only way for complex apps that doesn't end in chaos.

Yes, because it's showing how the simplest-possible mock already gets ugly if you don't follow the advice. Making the example more complicated would dilute the point it's making.

The question of "when to mock" is very interesting and dear to my heart, but it's not the question this article is trying to answer.

> I’m not sure this is good advice. I prefer to test as much of the stack as possible. The most common mistake I see these days is people testing too much in isolation, which leads to a false sense of safety.

You make it sounds as if the article would argue for test isolation which it emphatically doesn't. It in fact even links out to the Mock Hell talk.

Every mock makes the test suite less meaningful and the question the article is trying to answer is how to minimize the damage the mocks do to your software if you actually need them.

Pretty good, except it’s not Bismarck but Fontane. ;) Also, I’m comparing myself to CGP Grey, not whatever it’s transcribed. :D

ha, I wish I saw that while working on that talk! adding it to the resources!

Shouldn't some AI be able to clean that up for you? This seems something LLMs should be well-suited for.

---

FWIW, I'm the speaker and let me be honest with you: I'm super unmotivated to write nowadays.

In the past, my usual MO was writing a bunch of blog posts and submit the ones that resonated to CfPs (e.g. <https://hynek.me/articles/python-subclassing-redux/> → <https://hynek.me/talks/subclassing/>).

However, nowadays thanks to the recent-ish changes in Twitter and Google, my only chance to have my stuff read by a nontrivial amount of people is hitting HN frontage which is a lottery. It's so bad I even got into YouTubing to get a roll at the algorithm wheel.

It takes (me) a lot of work to crystallize and compress my thoughts like this. Giving it as a talk at a big conference, at least opens the door to interesting IRL interactions which are important (to me), because I'm an introvert.

I can't stress enough how we're currently eating the seed corn by killing the public web.

that's a reference to my attrs library which is what data classes are based on. It originally used

    @attr.s
    class C:
        x = attr.ib()

as its main api (with `attr.attrs` and `attr.attrib` as serious business aliases so you didn't have to use it).

That API was always polarizing, some loved it, some hated it.

I will point out though, that it predates type hints and it was an effective way to declare classes with little "syntax noise" which made it easy to write but also easy to read, because you used the import name as part of the APIs.

Here is more context: https://www.attrs.org/en/stable/names.html

I REGRET NOTHING

Both PDM and Poetry are a) 90% solutions that only cover what their respective authors need (and this is indeed what Python is drowning in) and b) written in Python which makes them slow and somewhat janky since Python installations and virtualenvs tend to break (lol Homebrew).

I personally love PDM, and PDM is in the process of adopting uv’s lower-leveln functionality to install/resolve packages, but I can see how having a single binary for bootstrapping a whole dev environment is really nice.

In the end, uv’s biggest upside is that it has several people work 8h / day on it and one would be surprised how much can be achieved in such amount of time.

That is inaccurate. Both Rye and uv have the same goals and support virtualenvs.

uv is meant to supplant Rye eventually (it mostly already has: see also this post by the creator of Rye: <https://lucumr.pocoo.org/2024/8/21/harvest-season/>). But you can’t put a virtualenv into a Kubernetes, so Docker containers are still interesting if that’s something you want to do.

It’s much, much faster both in creating virtualenvs and installing the dependencies. And if you use lock/sync, you get a cross-platform lockfile that you only got with PDM and Poetry before – no more requirements.txt (but it supports it too).

The burpee exercise is named after the US physiologist Royal Huddleston Burpee Sr.

I know y’all want to fact-check this – I sure did when I heard it the first time: https://en.wikipedia.org/wiki/Burpee_(exercise)

I guess PEP 703 has to be auto-accepted now. I don't make the rules.

Conceptually, Cython is mainly for accelerating Python code, and can _also_ access C code. Meanwhile CFFI is specifically for calling C code and nothing else. I recommend the video for the differences.

One concrete thing that pops to my mind is that Cython doesn't support Py_LIMITED_API which means that you need to ship a lot more binary wheels. At least the issue is still open (https://github.com/cython/cython/issues/2542) and Cython projects IME need new wheels for each minor Python release. Compare that to cffi projects that (musl & pypy aside) only have to ship wheels for one Python version / architecture: https://pypi.org/project/argon2-cffi-bindings/#files

Right, but that would take some really deep patching of code I don't control, just so it works in development.

If this were a production issue, I would probably fork the driver and do what you're suggesting (it's not like it's actively maintained or something :|).

You mean at the Python driver level? Unfortunately, that doesn't work with ctypes.

I've tried it by adding the DYLD_LIBRARY_PATH to os.environ before calling ctypes.LibraryLoader.LoadLibrary (https://docs.python.org/3/library/ctypes.html#ctypes.Library...) and it didn't work. I suspect ctypes gets somehow initialized much sooner and adding environment variables in your apps doesn't help.

TBH I didn't research it further, since the problems of the post are more general and it can happen that you trip into them regardless of runtime.

That doesn't help you if there's a surprise call to /bin/sh or /bin/bash somewhere in the call stack. Keep reading, I know it's long but I tried to make it comprehensive. :)

They did (it's me :)) and unfortunately in this case rpath can't be used, because that particular Python driver uses ctypes (https://docs.python.org/3/library/ctypes.html) to open the binary drivers which oversimplified means that there is no binary top modify.

I hope I make it in the preamble clear that this is bad and one should not have to deal with this – but it happens in practice and I hope such a summary is useful.

For posterity: if you want to wrap / use a C library in Python, you should go for CFFI (Cython works too and is overall faster, but has other downsides). This PyCon US video is a great up-to-date summary: https://www.youtube.com/watch?v=gROGDQakzas

Heh sorry I put the date there in the draft phase because I planned for publishing on Tuesday.

It got done earlier and I pushed it out in a bit of a hurry because I was leaving and forgot to update the date.

I have fixed it.

I’m aware of all the problems that e2e tests have, and yet I find it more useful to have 1 test that adds something to a basket and 1 test that removes it than 100 unit tests without contract tests (which I never got the hang of TBH).

(To be fair, my projects are low on JavaScript which somewhat changes the trade-off calculations, but I haven’t seen any assertions about project types above.)

No, it doesn’t pass over that. It specifically points out that it’s a simplistic example for illustration that probably wouldn’t be worth it. And yet the effects are visible and so are the problems/solutions.

I mean what do you want here? 1,000 LoC in a blog post so it feels worth it?

I’m sorry I’ve apparently misunderstood your point. I guess I’ve never seen too brass imparting more than a big picture “we’re writing tests now”.

I know you’re being facetious but: the lesson is rather that mocking generic third-party APIs is so easy, that you can end up in mocking hell real fast. And that you should take the harder route for your future sanity.

One of the reasons I wrote the linked article is that the wisdom around is quite fragmented and one (there’s always more than one) frustrating answer is good design makes software testable: “the deep synergy between testability and good design”: https://m.youtube.com/watch?v=4cVZvoFGJTU

Writing unit tests for software that is testable is easy. The hard part is to write testable software. But then there’s people who will argue that making software testable often leads to “test damage”.

As always, trade-offs & personal preference.

Cue Mock Hell https://www.youtube.com/watch?v=CdKaZ7boiZ4 :)

I can assure you that it is possible and meaningful to have full code coverage in certain contexts (for instance for important projects that get only rarely touched) and doesn’t inevitably lead to bad test suites.

Railing against code coverage is at this point just as dogma as insisting on it.

FWIW I’m a former senior-less junior that programmed himself into a hole. My blog and conference talks are exactly the material that I’d loved to have had ~10 years ago.

Not sure if I’d have been smart enough to take my advice though. ;)

> You don't need to build a facade for every api client (the api client is already a facade).

I feel like this is covered by

> Every rule and principle can be broken once you’ve fully understood its purpose. For example if an object already does have an idiomatic API, it’s probably not worth wrapping in an identical façade, just so it belongs to you.

?

I personally prefer pytest-httpserver that is a bit more low-level, but I still prefer idiomatic calls over sprinkled http requests on business code.

I put the disclaimer there, because I was afraid people would stop reading and start arguing about mocks vs fakes vs etc. But you’re right, people skip the lede (mentions counter-intuitive, I hoped that set the mood) and lose patience, so I’ll try to swap the blocks and see if the comments improve.

Being a gatekeeper from unit testing is the last thing I aspire to be, but past me (and that’s my imaginary audience) would’ve loved this explanation before he got some projects into mocking hell.

I’m the first to say that if you have no tests and no idea how to get start, go with end-to-end tests first and take it from there. That doesn’t mean that guidelines that help you to have less brittle and more idiomatic unit tests are bad per se IMHO.

I’m my experience, you get most of that kind of coverage with integration test/user story tests/however-you-call-them.

Solutions like vcr aren’t bullet-proof either and are a variation of in-process servers that the article mentions.

To put it differently: the question is not whether vcr, but _where_ vcr.