I've haven't looked at rust for some time so I have trouble giving good feedback on the suggestions you have. I thought I'd share some general thoughts I have on unit tests tho :)
In general, I think unit tests are important enough to deserve tight integration into the language and build system. I think iterations time are extremely important when working with unit tests. In particular two use cases are crucial: - Edit a single test, recompile, run just that one - Edit implementation, recompile, run a specific test If these iterations time take more than a second you immediately start losing cases where it's economical to write unit tests. If you keep both these iteration times sub-second unit tests can serve some of the purposes an interpreter does - and that's something really valuable. Here are my thoughts on how to acheive this; If you're testing code in a large module, that module must either incrementally rebuild superfast or each test file could be built as a separate module. In that case you'd only include the source files that it actually needs. These files could either be specified manually or inferred from the imports. Please consider making a framework that scales to really large projects :) Being able to test things that shouldn't compile becomes more important the more compile time/macro features a language has. It would also be nice if compile time tests looked similar to runtime ones. Cheers, Johan Torp On Fri, Oct 22, 2010 at 9:00 PM, <[email protected]> wrote: > Send Rust-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.mozilla.org/listinfo/rust-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rust-dev digest..." > > > Today's Topics: > > 1. unit testing (Graydon Hoare) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Oct 2010 14:40:56 -0700 > From: Graydon Hoare <[email protected]> > To: [email protected] > Subject: [rust-dev] unit testing > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 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 > > > End of Rust-dev Digest, Vol 4, Issue 6 > ************************************** >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
