On 10-12-26 07:58 PM, Brian Anderson wrote:
I'm not familiar with D. What's the advantage of integrating unit testing so tightly with the compiler? What does this provide over xunit-style frameworks that just use reflection to find and run tests?
What I said in the email: I'd like to err on the side of "discoverable" over "configurable". Configuring a unit testing framework is nice; but I've seen far too many projects fall down the slope of "didn't even agree on how to do unit testing, decided someone else would get around to it, resulting system has no tests".
I want our library and ecosystem of programs to have a falling-down-easy, standard, discoverable-as-stdio kind of mechanism for doing unit tests, so it always gets done. Likewise logging. It's more important to have a system that gets used than to have a maximally flexible one.
(At least *some* amount of integration with the compiler or build process is necessary in a systems language like this, because ultimately the output file has to say where the OS drops a PC when the image is loaded into memory. Someone has to tell the compiler not to jump to 'main'. This is why we have a -shared flag currently in rustboot as well, for libraries.)
It seems like if you went this route, where you're defining the canonical test framework for the language, that it should be done in a very neutral, minimal and extensible way so that other test frameworks can piggyback on it.
Well, a bit. How about "defining *a* canonical test framework". Maybe lightly extensible (an obj interface you can provide your own impl for), but I mean, basic test-reporting interfaces shouldn't be that hard. If a standard library can provide things like containers, PRNGs, IO systems, file formats, OS interfaces, i18n and debug interfaces ... it seems like it can provide a unit test framework. Many languages provide such now.
-Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
