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:
#[cfg(test)]
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.
2 Likes
Now, I am wondering what other gems I am missing.
Somebody should write an article: Fantastic Packages and where to find them!
5 Likes
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.
2 Likes
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
https://tlienart.github.io/FranklinTemplates.jl/
1 Like