How to use workspaces to test?

General Usage
21

That runs the tests. I asked if I want to run functions in test.

function testInvalidCodeword(cw::Codeword)
  dec,bits,codeBits,upsideDown=decode(cw,false)
  bits<0
end

function testInvalidCodeword(cw::Vector{<:Integer})
  testInvalidCodeword(Codeword(cw))
end

@test testInvalidCodeword([0x1f,0x54,0x7f,0x7f,0x55,0])
# This has a run of 16 bits. Real Mumzel has no run longer than 11.
@test testInvalidCodeword([0x46,0x36,0x17,0x4e,0x2c,0])
# partB is 249; the maximum valid is 223, except for syncwords.
@test testInvalidCodeword([0x16,0x69,0x4a,0x6d,0x12,1])
# This is row 265 of the 270 rows of pattern 43425, but only 256 rows are used.

This code is in runtests.jl. If I’m writing a new test, I’d like to call testInvalidCodeword interactively with various codewords before I add a test to runtests.jl. How do I do that?

22

Just open a Julia REPL in your test environment and run that file line by line?

1 Like
23

I think we’re a bit confused because these two statements from your two comments sound contradictory. You said “instead of running ]test”, which is what you would normally do to run those @test statements in your runtests.jl. So I think most of us read that and think you must want to run those @test statements somehow (and there are indeed multiple ways). But your second comment says that’s not what you want.

If you don’t want to run those @test statements, but do want to use testInvalidCodeword, you somehow need to include the code that defines those functions. But you probably don’t want to just include("runtests.jl"), because that will run the @tests. You’ll probably want to extract the function definitions into some other file, then include that file into runtests.jl so that your tests will still run, and include that file when you’re calling the functions interactively.

I don’t know where decode and Codeword are defined, but if they’re in a package, then whatever environment has that package will need to be active. If it’s your main package, you could run it from your package’s environment; if it’s only in your test environment, you’ll need to activate your test environment.

Most of this is the same as it was before workspaces came into being. (See also TestEnv.jl.)

24

decode and Codeword are defined in the main package. testInvalidCodeword is defined in the test workspace. I’d like to run testInvalidCodeword from the REPL, but the only way I know to run a function in runtests.jl is to type test in Pkg, which recompiles the whole package. If I have to run all the tests to call testInvalidCodeword from the REPL, that’s okay; they don’t take long. But I don’t yet know any way to call functions defined in the test workspace from the REPL.

25

I would argue that those functions are not defined “in the test workspace” at all; they are defined in the runtests.jl file (currently). Basically, what happens when you do ]test is that Julia’s Pkg manager just includes the tests/runtests.jl file. The fact that ]test does some environment weirdness is separate from the fact that you happened to define your functions in that file.

So if you want to use those functions in your REPL session, you need to define them. You need to tell your REPL session what they are; just putting them somewhere in the environment won’t do that. That’s why I suggested putting them in a separate file and calling the include function on that file from your REPL.

You might also be interested in TestItems.

26

What’s the main file in a workspace? If I run julia --project -t auto in the Foo repo, then using Foo, it loads Foo/src/Foo.jl. If I then activate test, what using command do I give, and what file in Foo/test/ does it load?

27

This sounds like some kind of confusion. The reason using Foo loads src/Foo.jl in that scenario is that you have activated an environment that defines a package called Foo (because Project.toml contains a name, with value Foo, and a uuid) and src/Foo.jl is where the package loading looks for the source code.

When you activate the test environment, that won’t be a package environment and there’s no mechanism by which using X would load something in the test directory just because that contains your activated environment.

28

The article at Julia 1.12 brings progress on standalone binaries and more [LWN.net] contains a section on workspaces and shows how to set them up.

2 Likes
29

I found that 1.11 occasionally rearranges a version on top, as in

name = "Whatever"
uuid = "some-UUID"
authors = ["Tamás K. Papp <tkpapp@gmail.com>"]
version = "0.1.0"

[workspace]
projects = ["test", "debug"]

to

[workspace]
projects = ["test", "debug"]
version = "0.1.0"

at the bottom, making 1.12 baffled.

(I am currently running a project where I use 1.11 for the estimation which needs Enzyme, which is still catching up to 1.12, and 1.12 for everything else; otherwise it works fine, with version-specific manifests. I am in workflow heaven. :palm_tree:)