I'd like to see more languages with built-in, language level support for unit tests. Pyret (https://www.pyret.org/) does this but is considered a "learning language". I'm aware that to many people co-locating units tests with the functions they're testing is "bad" but I find it to be quite the opposite. The two are so tightly coupled that having the unit tests in a separate file, sometimes in a separate source tree, is counterintuitive to me.
It's true that Racket unit tests are an optional module within the standard library, but the command line tools and package system work directly with it. You can place unit tests right alongside the regular code but within a specially-named "test" submodule, so the unit test code doesn't run at runtime by default, except in certain contexts (package installation, "raco test" command, or running the file from within the Racket IDE).
Yea, I like this about Racket unit tests. It really lowers the barrier to writing tests, and you don't have to go creating separate test files in specific locations.
You can do this in Rust. Just put a namespace tagged as I think #[cfg(test)] or the like and they can live in the same file but won't be compiled into the non-test binary.
It could be interesting to think about unit tests and contracts together. In theory a function is valid for anything allowed under its contract, which could make generative testing (aka property-based testing) more powerful and automatic.
It would also be nice to have system-level contracts. Like, say, "every item in list X should have an entry in dictionary Y". Or "no button should be located outside the visible viewport". These are the sorts of things that people procedurally unit test, but expressed in a declarative way you can imagine all sorts of tooling.
