←back to thread

Unit tests as documentation

(www.thecoder.cafe)
118 points thunderbong | 1 comments | | HN request time: 0.199s | source
Show context
rglover ◴[] 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 ◴[] 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 #
rglover ◴[] 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 #
1. BeetleB ◴[] 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.