Writing tests in VS Code: workflow, autocomplete, and tooltips

General Usage
, ,
1

Hello all!

I’m currently writing a package for the purpose of learning Julia, and am finding that autocomplete & hover-tooltips for types defined in the package do not seem to appear when in a test file.

Problem
Specifically, suppose I’m writing a package called Moo, and I have the usual package structure. within src/Moo.jl vscode will give tooltips/autocompletion for functions and types defined therein.

Now I have some tests too. I have test/runtests.jl, which includes test/some_tests.jl. If I’m editing some_tests.jl then such tooltips appear to be unavailable.

I’ve tried restarting the language server, restarting vscode, and reindexing the language server cache; none seem to change the behaviour.

Is this behaviour expected? In case the answer is “no”, I’ve gone into a bit more detail on my workflow below in case it has relevance…

Workflow
[[NB Aside – I’m pretty new to Julia and the associated tooling! I’m doing my best to figure out established best-practice-workflow, and sticking to what seems to be common structuring of packaging & projects. I’m coming from primarily Python, also some Kotlin, and C++. Any suggestions and tips would be most welcome! :slight_smile: ]]

When writing tests, I’m currently switching between a Julia REPL [in which the Moo development directory is activated] and running pkg> test. This obviously runs all the tests… not a problem right now, but I can imagine this becoming frustrating if some tests are longer-running.

The only other way I’ve found to run the tests that works is using Alt-Enter in runtests.jl, but since this requires switching files it seems rather less convenient. Alt-Enter in some_tests.jl doesn’t work, as the Test module is only imported in runtests.jl… this seems to be standard practice though? [This concept – the writing of a source file which does not contain sufficient information to be runnable – is somewhat alien to me, yet seems to be very common in Julia. In Python you’d always import anything used, and in C++ you’d include headers.]

Am I missing something? Is there a better / faster way? And maybe this is related to my autocompletion apparent non-functionality?

Thanks very much!

4 Likes
2

Hi and welcome! Great question and I’ve had similar frustrations myself, and haven’t really found a great solution.

One workaround I did find (from https://github.com/julia-vscode/julia-vscode/issues/800) that works is this at the top of a script:

#  VS Code workaround: https://github.com/julia-vscode/julia-vscode/issues/800
if isdefined(@__MODULE__, :LanguageServer)
  @info "Using VS Code workaround..."
  include("Moo")
  using .Moo
else
  using Moo
end
1 Like
3

Thanks very much - looking at that issue, I agree it covers this case, so sadly this does seem to be expected for the time being.

[For the record, I just made a minor adjustment to your suggestion, and then it works exactly as you said :slight_smile: : include("Moo") → include("../src/Moo.jl") . ]

I’m marking this as “solved” since you definitely answered my main question re intellisense, although if anyone else has thoughts on the general workflow of writing & running tests then would still very much like to hear it!

4

Ah, yes that was just me being sloppy when I replaced what I had with your package name. Let it not be thought that I create Julia source files without the .jl extension! :laughing:

5

I tried it out with one of my packages. I can confirm, as you had observed, that the tooltips in source files inside the test folder were not present as long as the package was not installed via e.g. (@v1.6) pkg> add Moo.

But as soon as I did a (@v1.6) pkg> dev Moo, I saw LanguageServer indexing Moo and thereafter I got fancy tooltips.

6

Interesting - thank you!

Apologies if I misunderstood here, but should I read this as deving being recommended [[i.e. using an environment independent to the project environment into which the package being developed is added via `dev`]] when developing a package from scratch? The documentation etc. I’ve found so far suggest it as a mechanism for easily checking out an existing package for the purpose of making changes, but not in the context of making a new package.

Or was this just an example of a workflow that happens to make the tooltip thing work, but that one wouldn’t ideally want to use in practice? :slight_smile:

7

at a certain point in developing a package it simply becomes convenient.

The documentation says:

when you are developing a package, it is more convenient to load packages at their current state at some path. For this reason, the dev command exists.

Why not use it, if it makes your life easier?

8

I interpreted this section of the manual to mean “easier than using add”…? I was imagining the following scenario:

  • I’m working on some project (i.e. not a package) with one or more dependencies that I’d like to edit.
  • I can dev those packages in the context of that project’s environment.
  • If I used dev --local Moo (*), then these packages would appear under the same directory of the project… so I’d end up with:
some_project_dir/
    Moo/
        src/
        test/
        ...
        Project.toml
    Project.toml

but then always have some_project_dir as the active environment? (I was under the impression that most people avoided using the global environment so as to ensure isolation between activities, which is how I’d work in e.g. Python too.)

If I’m just working on Moo, then naively this doesn’t seem simpler/easier, but maybe I’m missing something? … maybe there is a rule of thumb that one’s active environment should always be a non-package environment, rather than a package environment, and there are other reasons that this is preferable/cleaner? But then I’m not convinced by that, as if I need to add a dependency to the package then I would need to be in the context of the package env :slight_smile:

Also, apologies for the extensive questions – I have spent an embarrassingly long time scouring the internet off-and-on over the last days/weeks trying to understand how the package & module system works, and find a consensus on various workflow-related matters!

(*) Or refer to an explicit check-out of the package. For sanity when using VSCode I would have thought one would want to retain the packages one is editing in the context of a particular project under that project’s directory(?)

9

Sorry, that I can’t comment much on the workflow, you describe. I can only say, that I started out (coming from python) years ago in a very similar way. After I adopted to package development under .julia/dev, life got so much easier.

Projects for me are mainly scripts or notebooks, organized differently from packages. The dev strategy allows you to have your private packages, which you can use in your projects.