Rust-like source-file tests

I find the idiomatic Rust way of writing tests extremely practical, and I can only imagine that such an approach would add even more value to a language like Julia.

Although tools like Copilot can have project-level access, the quality of suggestions seems superior when operating in a source file-level context.

For those not familiar with the Rust test writing, at the end of the/any source file, append the tests relevant to the functionality defined in that file:

mod tests {
    # add dependencies and write tests here

The above will be run when invoking cargo test, and (obviously) the tests will not be part of the final/compiled binary.

P. S. I acknowledge the high level of subjectivity and preference when discussing this subject. I am just curious about what the community thinks about this.


Now, I am wondering what other gems I am missing.

Somebody should write an article: Fantastic Packages and where to find them!


I think you misspelled


MoJuWo was my first stop before posting the question.

I am unsure if putting testing under the sharing category aids discoverability (maybe it will not matter so much once a search functionality is added to MoJuWo).

1 Like

Wouldn’t including unused test code in the source code increase the compilation time each time the code is included in the Julia? I think this test section should be omitted in the parsing level of compilation which seems like a comprehensive change - which in turn with a computation overhead in each single use of include ?

Yes, this is more or less what’s done in TestItems.jl: @testitem code blocks are expanded to literally nothing at macro expansion time, so that they are not compiled.

Sure, this probably incurs some overhead when includeing test files, but I doubt it is significant.


Sorry for the aside

Maybe it’s the name of the category that’s not optimal? How about “Packaging”?

I don’t know if there is a way to do that with the standard Franklin themes? @tlienart would know

1 Like