UnitTest project directory structure for libraries and submodules?

Users
1

Hello, I had a question about project file structure for a Chapel library. I’m confident I have the src directory structure working, per the great discussion in Importing files from subfolders . I’m assuming:

src/
  MyLibrary.chpl
  MyLibrary/
    Submodule1.chpl
    Submodule2.chpl

Now I’d like to write UnitTests for that hierarchical library structure. I was thinking something like

test/
  MyLibraryTest.chpl
  MyLibraryTest/
    Submodule1Test.chpl
    Submodule2Test.chpl

Where MyLibraryTest simply includes the lower test submodules and calls UnitTest.main(). In Submodule1Test I then have

module Submodule1Test {
  use UnitTest;
  import Submodule1;
  // tests go here
}

But Mason is unable to find Submodule1, and won’t be able to run the tests. Should I move to a flat test directory structure?

test/
  Submodule1Test.chpl
  Submodule2Test.chpl

I think this would work, but then each test file would need a

proc main() throws {UnitTest.main();}

is that best practice?

2

Hello @jmag722,

As a quick response, I wouldn't be surprised at all if UnitTest or mason test has some gaps w.r.t. walking a directory tree the same way our compiler does.

is that best practice?

Today, that's the case. In my Mason packages, I have flat structure and that line in all of the files. That's not to say that we should be satisfied with that, though. :slight_smile:

Engin

1 Like
3

Thank you Engin. I also noticed with the VSCode extension, where you can run the tests directly in the editor, I believe it needs UnitTest.main in each file or it can’t run the tests (it could “Run All” from my MyLibraryTest.chpl but not individual tests from the submodule tests).

4

Hmm, that could be the extension inheriting the behavior from UnitTest. But I'll tag @jabraham to make sure that they see it and in case there is an issue with the extension.

Engin

5

That's correct, each file needs its own UnitTest.main. If you have a single UnitTest.main and include multiple files with tests of their own, mason should understand that fine, but the VSCode extension won't. But this is definitely on the roadmap as future work

-Jade

6

Thanks you both, flattening the test structure allows VS code tests to run individually. Structured now like:

module MyLibrary {
  include module Submodule1;
  include module Submodule2;

  public import this.Submodule1;
  public import this.Submodule2;
}

with

module Submodule1Test {
  use UnitTest;

  import MyLibrary.Submodule1;
  // ...
}

allowed tests to run in both the editor and with mason test. But the import MyLibrary.Submodule1Test still had a red squiggly saying MyLibrary couldn’t be found, but guess it’s not a problem.

-Jared

7

Thats due to chpl-language-server in VSCode not being able to understand your project structure, whereas mason understands it out of the box. Its not a problem, its just a visual thing. But you can resolve it.

There's an open issue about better out of the box support for mason projects, [Feature Request]: Integrate CLS better with Mason · Issue #25120 · chapel-lang/chapel · GitHub. But you can also add the following to the bottom of your mason file and the red error lines will go away

[tool.chpl-language-server]
module-dir = ["src"]

-Jade

8

Thank you Jade, that did the trick!

Best,

Jared