# How do I activate the test environment of a package?

**URL:** <https://discourse.julialang.org/t/how-do-i-activate-the-test-environment-of-a-package/86740>\
**Category:** Package Management\
**Created:** [September 3, 2022, 7:09pm UTC](https://discourse.julialang.org/t/how-do-i-activate-the-test-environment-of-a-package/86740 "2022-09-03T19:09:11Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![lamorton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lamorton/32/21115_2.png) [@lamorton](https://discourse.julialang.org/u/lamorton)\
**Post date:** [September 3, 2022, 7:09pm UTC](https://discourse.julialang.org/t/how-do-i-activate-the-test-environment-of-a-package/86740/1 "2022-09-03T19:09:12Z")

</div>

I want to do some testing of changes to a package I’ve `dev`ed. I activate the package environment, but it doesn’t have some imported packages I want to use during testing. (For concreteness, I’m working on `ModelingToolkit` and I want to use `OrdinaryDiffEq`.) Now, I see that there’s a test target in the package’s `Project.toml` which includes `OrdinaryDiffEq`.

I tried `activate test` but I got:

```julia
(ModelingToolkit) pkg> activate test
  Activating new project at `C:\Users\lucas\Documents\Code\Jdev\ModelingToolkit\test`

```

which is not what I intended. What should I be doing instead? I don’t think I should be adding `OrdinaryDiffEq` to the base environment of `ModelingToolkit` here. (First of all, it’s not meant to be a dependency, and second, IDK if I’ll get the right version number.)

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 3, 2022, 7:28pm UTC](https://discourse.julialang.org/t/how-do-i-activate-the-test-environment-of-a-package/86740/2 "2022-09-03T19:28:22Z")

</div>

Try [GitHub - JuliaTesting/TestEnv.jl: Activate your test enviroment, so you can use your test dependencies in the REPL](https://github.com/JuliaTesting/TestEnv.jl)

Not perfect (because you need one more package), but works for me…

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [September 6, 2022, 1:15pm UTC](https://discourse.julialang.org/t/how-do-i-activate-the-test-environment-of-a-package/86740/3 "2022-09-06T13:15:12Z")

</div>

My workaround is to

1. activate the test environment,

2. put `..` in `LOAD_PATH`.

I have utility functions for this in my startup file. It is kind of a hack, but it works.

```julia
function put_in_load_path!(dir = "..", pos = 2)
    if dir ∈ LOAD_PATH
        @warn "$(dir) is already in LOAD_PATH"
    else
        insert!(LOAD_PATH, pos, dir)
    end
    LOAD_PATH
end

function del_in_load_path!(dir = "..")
    pos = findfirst(isequal(dir), LOAD_PATH)
    if pos ≡ nothing
        @warn "$(dir) is not in LOAD_PATH"
    else
        deleteat!(LOAD_PATH, pos)
    end
    LOAD_PATH
end

```

---

<div class="post-metadata">

**Author:** ![jlperla](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlperla/32/34332_2.png) [@jlperla](https://discourse.julialang.org/u/jlperla)\
**Post date:** [September 6, 2022, 4:30pm UTC](https://discourse.julialang.org/t/how-do-i-activate-the-test-environment-of-a-package/86740/4 "2022-09-06T16:30:36Z")

</div>

> [@ufechner7](#):
>
> Try [GitHub - JuliaTesting/TestEnv.jl: Activate your test enviroment, so you can use your test dependencies in the REPL](https://github.com/JuliaTesting/TestEnv.jl)

Yup, this is the winner for sure, and doesn’t require **any** non-dev tool packages in your global environment. [How to use VSCode and REPL to write and test a package? - #4 by jlperla](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818/4) writes up what I found to be the easiest workflow. If a package doesn’t have a `test/Project.toml` but has it embedded in the main Project file, I think TestEnv is still supposed to work.

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [September 6, 2022, 6:03pm UTC](https://discourse.julialang.org/t/how-do-i-activate-the-test-environment-of-a-package/86740/5 "2022-09-06T18:03:55Z")

</div>

> [@jlperla](#):
>
> has it embedded in the main Project file, I think TestEnv is still supposed to work.

Yes, it works for both cases

---

<div class="post-metadata">

**Author:** ![huguesmp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/huguesmp/32/202444_2.png) [@huguesmp](https://discourse.julialang.org/u/huguesmp)\
**Post date:** [October 9, 2022, 1:17pm UTC](https://discourse.julialang.org/t/how-do-i-activate-the-test-environment-of-a-package/86740/6 "2022-10-09T13:17:38Z")

</div>

I have a question on this workflow, if I may.

I’m new to Julia and still trying to get a feel for a preferred workflow. So far, I have found I can:

- Keep my projects in `~/.julia/dev`, which is done automatically when using `PkgTemplates`
- Use `project=true` while creating my project, so that there is a `Project.toml` file in `./test`
- While in the global environment, use `] dev MyPackage` so that my code is reachable from the test environment via stacking
- In vscode, have the repl activate the test environment, and then use TDD from there

From my (limited) testing, it seems the language server in vscode can stay in the project environment, providing completions, etc.

So far, I’ve been able to write tests, modify code to make them pass, with the use of `Revise.jl` by the vscode extension making it pretty seamless.

What I’d like to know is if I’m missing something here (I suspect I am), and in what ways this workflow differs from the `TestEnv` method, or if it is mainly equivalent and just a matter of preference.