I was initially skeptical about Rust's convention of having tests in the same file as the actual code, but it seems to be working out well.
-
It's difficult enough to keep compatibility across versions when you're programming against a public API. With tests, you often want to check internals.
Oh, you wouldn't, but the fact it's hard at the moment is sort of the point: If the tests aren't in sync with your main repo, then some of them would just fail (at compile time). You would update them if/when you care enough to do so, but no requirement for it to be synchronous.
-
-
That sounds like a recipe for deterioration.
-
Deterioration of what?
- Show replies
New conversation -
-
-
By the way, everything I'm saying about tests could be applied to documentation too. It's maybe more understandable for docs.
-
Docs are different in that they're often not mechanically checked and also timeless (or exist on a different timeline than the code, e.g. by also pointing out beta or deprecated features).
- Show replies
New conversation -
-
-
Isn't that the equivalent of "I'll write the tests later"? If you release untested code into production, the difference between writing the tests later and never writing them is close to none.
-
But it decouples the two, but doesn't change anyone's standards on whether the deploy untested code. And it leaves open the possibility of someone writing those tests later, which would otherwise be closed.
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.