For those who don’t want to watch a long video, could you please summarize the gist of that approach?
I mean 2.
The video talks about TDD, which is a great workflow for coding.
With respect to this discussion, Chris also used Pkg.test("PackageName") function in REPL. Here’re my observations when I tried to use it for my package development:
Pros
- It works flawlessly, even if I make changes to a struct (for which Revise could not work… at least with Julia v0.6.2… not sure about v0.7)
Cons
-
It takes a few seconds to run (seems to have some startup overhead).
-
It runs the whole test suite from
runtests.jl. That’s probably not too annoying if the tests run quickly. When I test SASLib it goes through many file read operations so it’s less efficient than using Revise. -
It does not recognize the package if it’s not installed in the Julia’s standard package directory.
I see. I would say that this is mostly a solution to an orthogonal question. One can do TDD independently of using Revise.jl.
Right.
In the video, Chris also demonstrated the use of Pkg.test function. I’ve clarified in my post above as such.
Indeed, this is an open issue. See
Using the eval-in-module functionality in Juno was frequently used as a manual “poor man’s Revise” before Revise was made. The great thing about Revise is that there is no need to manually evaluate the things you want to update. That is taken care for you.
4 Likes
I do that after I think something works because Juno in-module or Revise utilize your current state, and sometimes you’ll mix random stuff from the REPL with your tests and it’ll “work”. Pkg.test tests in a completely clean environment to make sure that nothing can be wrong. But since it then runs all of the tests, that’s why I use it sparingly, and most of the video is how to avoid Pkg.test.
As @kristoffer.carlsson stated, Revise.jl is a more powerful form of what Juno has built in. You could use either one to do development like this, YMMV.
1 Like
Certainly not mutually exclusive, but when thinking about modifying the default Julia experience (and documentation, and tutorials presumably?) to enable better workflows, I think it is important to consider ways people work with Julia. The Chris workflow makes TDD easy, but you don’t need to use it.
The reason I like the Chris workflow is that you get immediate feedback after you modify your core functions (ie the shift-enter tells you if it compiles), the visual feedback is local to what you are modifying, and it doesn’t need to recompile or mess with any other functions.
Then when you are messing with the code to test your modified functions, you can do it in whatever order you wish (ie you can just execute the lines of testing code effected by your modified function with a shift enter) and the visual feedback is again local to where you are running the code. Of course, you need to run the full Pkg.test eventually, but not while you are figuring things out.
Not to say that this is necessarily incompatible with Revise.jl workflow, but I haven’t tried that approach with Revise turned on… For example, if I happen to save my file while doing my approach, would revise end up recompiling a whole bunch of things, redoing the using, etc? Not sure,but I think some testing should occur before merging Revise.jl into the default experience
Should that be the ChrisWorkflow™? 
Give the Juno team the credit.
2 Likes
Exactly. I pretty much follow this work flow:
- Use REPL for testing
- Use Revise so I don’t have to restart the REPL when a module is changed
- Restart REPL when Revise fails to hot swap my change e.g. struct changes
I’m unsure if Pkg.test() is any better than just invoking the test script from the shell. In fact, when I have multiple test scripts, I would rather run a test script that’s targeted for my change. Then, once in a while, I would invoke julia runtests.jl to ensure that nothing is broken.
1 Like
Hate to do this again, but Rails has this cool tool called guard that automatically runs tests as you save files.
// you can manually configure it so that it regex’s to find all relevant tests
https://github.com/guard/guard-minitest
I always thought Revise.jl could be the cornerstone of a dev framework for all sorts of toys like this (e.g. testing)
2 Likes