So coming to scientific computing it's understandable that I was taken aback by
the lack of testing. Complex packages, with novel ground-breaking algorithms,
grep test ** returns nothing. How do I know this works as intended, let
alone the author?
When I initially found Julia, I was impressed by all of the 21st century
nicities, a package manager built-in, documentation generators, and packages
that have plans if they were to become orphaned. However, what I haven't really
dug into yet, is what the testing workflow looks like in Julia. I've noticed
plenty of tests in repos and read through them, but what interests me more, is
"what the developer experience is like?". Does writing and running tests bring
joy and save time? Can I run one test at time? Can I fire off all the tests
easily(and reproducibly) before I push a commit? Testing in Rust is currently
what I judge other language frameworks by(I'm open to suggestions if anyone has
a better recommendation to check out to form my opinions!).
cargo test and
cargo test one_hundred are examples of what I was talking about earlier.
After some research…
In the process of starting to answer some of those questions I had, I found a wonderful article by Erik Engheim, "Julia v1.5 Testing: Best Practices". I highly recommend you give that a read, I'm going do my best to avoid duplicating his efforts.
Takeaways from Erik Engheim's other article
This is a great article. As someone who's played around with a lot of lisp, the REPL is a great feature(and the Julia REPL is a lot less clunky than python's in Emacs), as he makes the point the REPL allows for "Rapid Iteration in Context". I was really excited to see we shared similar views of iterate interactively, then solidify by writing the tests down
Unlike TDD, you don’t write the tests ahead of time. Instead as you develop the code in the REPL interactively you are both exploring how to create the code as well as how to test it. This new insight may help you define sensible tests to avoid future regressions in the code you have written.
It is also worth keeping in mind that nothing prevents you from using a mixed approach.
Writing tests first might be a good exercise to get an outline of what you're trying to accomplish, and then going back and filling those tests in as you write the code.