←back to thread

Unit tests as documentation

(www.thecoder.cafe)
94 points thunderbong | 5 comments | 17 Oct 24 17:22 UTC | HN request time: 0.001s | source
Show context
rglover ◴[17 Oct 24 18:03 UTC] No.41872038[source]▶
Just write the docs. A simple template:

- What is it?

- What does it do?

- Why does it do that?

- What is the API?

- What does it return?

- What are some examples of proper, real world usage (that don't involve foo/bar but instead, real world inputs/outputs I'd likely see)?

replies(3): >>41872068 #>>41872141 #>>41873752 #
MathMonkeyMan ◴[17 Oct 24 18:13 UTC] No.41872141[source]▶
I was going to say that unit tests have the benefit of breaking when the truth changes.

But then I realized that a lot of what makes a set of tests good documentation is comments, and those rot, maybe worse than dedicated documentation.

Keeping documentation up to date is a hard problem that I haven't yet seen solved in my career.

replies(4): >>41872241 #>>41872394 #>>41872424 #>>41874894 #
1. rglover ◴[17 Oct 24 18:22 UTC] No.41872241[source]▶
The only fix for that is discipline. You can't automate away quality. The best people/teams understand that and make good docs a feature requirement, not an afterthought.

My favorite example is Stripe. They've never skimped on docs and you can tell they've made it a core competency requirement for their team.

replies(3): >>41872339 #>>41872469 #>>41876506 #
2. MathMonkeyMan ◴[17 Oct 24 18:31 UTC] No.41872339[source]▶
I wonder if there's some conservation law for "concerted mental effort." As if by spending time and energy on the often exasperating task of keeping documentation relevant, you reduce the time and energy required to comprehend the system.

You're right, it is a matter of culture and discipline. It's much harder to maintain a consistent and legible theory of a software component than it is to wing it with your 1-2 other teammates. Naming things is hard, especially when the names and their meanings eventually change.

3. hitchdev ◴[17 Oct 24 18:41 UTC] No.41872469[source]▶
I dont think it is about discipline. Discipline is required if you're duplicating tedious work, not for creativity.

At its core, a good test will take an example and do something with it to demonstrate an outcome.

That's exactly what how to docs do - often with the exact same examples.

Logically, they should be the same thing.

You just need a (non turing complete) language that is dual use - it generates docs and runs tests.

For example:

https://github.com/crdoconnor/strictyaml/blob/master/hitch/s...

And:

https://hitchdev.com/strictyaml/using/alpha/scalar/email-and...

replies(1): >>41875786 #
4. invaderzirp ◴[18 Oct 24 02:09 UTC] No.41875786[source]▶
No, you just need to both understand how your system works and then clearly write down what it's doing and why. If projects like Postgres and SQLite and musl libc and the Linux kernel can all do it, I think the CRUD app authors can do it, too. But it's not magic, and another tool won't solve it (source: I've seen a hundred of these tools on scores of teams, and they don't help when people have no clue what's happening and then they don't write anything down).
5. BeetleB ◴[18 Oct 24 05:05 UTC] No.41876506[source]▶
> The only fix for that is discipline.

The one lesson I have learned over my career: Don't work in teams (or for managers) that rely on discipline to get things done. Every time I've encountered them, they've been using it as an excuse to avoid better processes.

Sure, some counterexamples exist. Chances are, those counterexamples aren't where a given reader of your comment is working.