Hi Graydon, This is in response to an old thread about unit testing.
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? Googling doesn't turn up much. The only interesting thing I see is that compiling in unit tests causes the test suite to be run prior to main(), and that really doesn't seem very compelling since no user is going to have an interest in doing that. 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. Regards, Brian On Thu, Oct 21, 2010 at 5:40 PM, Graydon Hoare <[email protected]> wrote: > Hi, > > Rust presently has no "standard" mechanism for unit testing. I'd like to > adopt one, or at least move towards having one. We're getting enough library > written-in-rust code now that it makes sense. > > I'm interested in pursuing a slightly-structured technique, and have been > considering a mechanism similar to the D 'version' and 'unittest' system(s). > > The idea has three parts: > > 1. Add a command-line flag to specify a set of configuration flags to > enable during a particular build. say -cfg win32 or such. These are not > structured values, just opaque strings. > > 2. Add a syntax extension also called cfg that marks an item as > to-be-included only if one of its arguments appears in the set of > configuration flags. > > With 1 and 2, we'd be at the point where a module marked as, say, > "#cfg(test) mod test { ... }" would wind up conditionally compiled only if > you ran the compiler with -cfg test. (This would also double as a mechanism > for including modules on a per-platform basis, including debug code, that > sort of thing.) But programmers are lazy. So let's go one step further: > > 3. Add a *further* command-line flag called '-test' that does two things: > > - Adds #cfg(test) to the set of config flags, so all test-conditional > code gets included. > > - Changes the target the compiler's building. Instead of groveling > for a main function, or just building a library (as in -shared), > the -test target is a synthetic target that runs every function > marked with #test, passing in a value of type std.test.harness, > a basic xUnit-ish test harness. > > (should also provide runtime subset-selection of tests in the > harness, etc, etc., but you get the idea) > > If this works out nicely, we can expand the interface a bit in the future > to include specifying a test harness rather than hard-wiring it to the one > in std. For the time being I'd be happy to have any sort of structured > system, and I'd prefer to err on the side of "discoverable" rather than > "configurable" for testing. > > (Also, this way we increase the odds of the standard-library one maturing > along with community needs, rather than rotting away. Nothing sadder than a > standard library component nobody uses!) > > Comments? Preferences? > > -Graydon > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
