Lightnews — Scholar-powered news

Mark Seemann @ploeh.dk · 20h

New article: Result isomorphism. blog.ploeh.dk/2025/10/15/r...

Result isomorphism

Result types are roughly equivalent to exceptions.

blog.ploeh.dk

1 1 2

Mark Seemann @ploeh.dk · 6d

#repostfriday Changing your organisation. blog.ploeh.dk/2021/12/20/c...

Changing your organisation

Or: How do I convince X to adopt Y in software development?

blog.ploeh.dk

Mark Seemann @ploeh.dk · 8d

Other readers are showing their appreciation of ploeh blog by supporting it. You, too, can do that. blog.ploeh.dk/support

Support the blog

Ploeh blog is free, and always has been. Keep it free.

blog.ploeh.dk

Mark Seemann @ploeh.dk · 8d

This post, btw, rounded a corner of a sorts.

2

Mark Seemann @ploeh.dk · 10d

There used to be more 'engagement' in the past. People would repost, respond, or comment on SoMe (mostly Twitter), and believe it or not, add comments to the articles themselves.

There's not much of that left now. A bit, but noticeably less than a few years ago.

1

Mark Seemann @ploeh.dk · 10d

New article: Shift left on x. blog.ploeh.dk/2025/10/06/s...

Shift left on x

A difficult task may be easier if done sooner.

blog.ploeh.dk

1

Mark Seemann @ploeh.dk · 13d

Thank you, that's good to hear.

To be honest, blogging increasingly feels like no-one's reading...

1

Mark Seemann @ploeh.dk · 13d

#repostfriday Unit testing private helper methods. blog.ploeh.dk/2021/09/13/u...

Unit testing private helper methods

Evolving a private helper method, guided by tests.

blog.ploeh.dk

1

Mark Seemann @ploeh.dk · 15d

Not quite, but on the other hand, I currently don't actively seek conference appearance. I'll come if invited and we can agree on terms.

1

Mark Seemann @ploeh.dk · 15d

I've been reviewing some Python code that uses Result return types (via returns.readthedocs.io), and once more I refer to @eiriktsarpalis.bsky.social's excellent article 'You’re better off using Exceptions': eiriktsarpalis.wordpress.com/2017/02/19/y...

returns 0.26.0 documentation

returns.readthedocs.io

2

Mark Seemann @ploeh.dk · 16d

As things currently look, IT Days in Cluj-Napoca is going to be my only public appearance in 2025. www.itdays.ro

1

Mark Seemann @ploeh.dk · 17d

New article: Composing pure Haskell assertions. blog.ploeh.dk/2025/09/29/c...

Composing pure Haskell assertions

With HUnit and QuickCheck examples.

blog.ploeh.dk

4

Mark Seemann @ploeh.dk · 20d

#repostfriday Property-based testing is not the same as partition testing. blog.ploeh.dk/2021/06/28/p...

Property-based testing is not the same as partition testing

Including an example of property-based testing without much partitioning.

blog.ploeh.dk

Mark Seemann @ploeh.dk · 24d

It's striking so quickly the industry forgets that lines of code isn't a measure of productivity. blog.ploeh.dk/2025/09/22/i...

It's striking so quickly the industry forgets that lines of code isn't a measure of productivity

Code is a liability, not an asset.

blog.ploeh.dk

1 2

Mark Seemann @ploeh.dk · 27d

True. That, however, is not really my concern. Whether I have to edit 1 or 2 Repository implementations is a small problem compared to having to edit n tests. That's what I meant by O(1) edits versus O(n) edits.

1

Mark Seemann @ploeh.dk · 27d

While you wait for your work language to get discriminated unions: Your language already has discriminated unions. #repostfriday Visitor as a sum type. blog.ploeh.dk/2018/06/25/v...

Visitor as a sum type

The Visitor design pattern is isomorphic to sum types.

blog.ploeh.dk

1

Mark Seemann @ploeh.dk · 28d

If one were concerned about boundary cases, it might be reasonable to augment the test suite with some property-based tests, or perhaps even better, add mutation testing.

Mark Seemann @ploeh.dk · 28d

Why, however, didn't I discover that I also had to change my Fake implementation?

Because (being TDD artefacts) none of my tests were even close to that boundary.

Is that a weakness with TDD? You could argue that case.

2

Mark Seemann @ploeh.dk · 28d

The point of the example is that Mock-based tests are Fragile Tests. Abusing big-O notation, we can say that the cost of making the example refactoring is O(n), where n ~ number of tests.

Conversely, the cost with state-based testing is O(1). It doesn't really matter whether the constant is 1 or 2.

1 1

Mark Seemann @ploeh.dk · 28d

Yes, good point, and an astute observation that I didn't myself make. All tests passed, except the Moq-based test. I'll return to why that is in a moment, but I don't think it changes the argument; and neither does having to change the Fake implementation. That'll follow in the next post.