On Wed, Dec 29, 2010 at 4:53 PM, Graydon Hoare <[email protected]> wrote:
> 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.) That's what I was missing. I guess I'm pretty used to the JVM and CLR where there's not really a distinction between executables and libraries. I think I understand now. > > 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. I agree that providing a unit testing framework in the standard library is a good thing, and leaving the interface for defining tests open to other implementations is possibly all that's needed as an extension mechanism. I was thinking about the diversity of test frameworks in Java and how many of them provide some kind of JUnit adapter to ease adoption. It's good to leave people the option of building sprawling BDD frameworks and such on top of the standard one. -Brian
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
