I actually thought we should go the opposite direction and have tests in a different repository, evolving independently of the code they're testing. This would make it easier to check the behaviour of past as well as future versions of the code.
-
-
-
Replying to @larsr_h
I think only in the context of what we're currently familiar with. Trying to sell someone our current universe from my hypothetical alternative universe would probably make it seem a nightmare to them, too...
2 replies 0 retweets 0 likes -
Replying to @propensive
Fair point, so let's see: How would you handle compatibility between main and test repositories?
1 reply 0 retweets 0 likes -
-
Replying to @propensive
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.
1 reply 0 retweets 0 likes -
Replying to @larsr_h
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.
3 replies 0 retweets 0 likes -
-
-
Replying to @propensive
Your code. It'd be essentially like turning off the type checker. Once deteriorated, it's hard to repair again later.
1 reply 0 retweets 0 likes
No, it would be the opposite of that. You would be able to retroactively tighten the "typechecker" as you make it better, learning more about code that exists, is running (and maybe can't be upgraded easily).
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.