> So does this mean that neither did the original utils have any test harness, the process of rewriting them didn't start by creating one either?

Yes.

> Sure there are many edge cases, but surely the OS and FS can just be abstracted away and you can verify that "rm .//" actually ends up doing what is expected (Such as not deleting the current directory)?

I think people have been trying that since before I was born and haven't yet been successful, so I am much less sure than you are.

For example: How do you decide how many `/` characters to try?

For a better one: Can you imagine if "rm" could simply decide to refuse to delete files containing "important" as first 9 bytes? How would you think of a test for something like that without knowing the letters in that order? What if the magic word wasn't in a dictionary?

> This doesn't seem like sloppy coding, nor a critique of the language, it's just the same old "Oh, this is systems programming, we don't do tests"?

I've never heard anyone say that except as a straw man.

I've heard people say tests don't do what people think they do.

My understanding is the uutils development process involved extensive testing against the behaviour of the original utilities, including preserving bugs.