Does folder containing tests have to be called "tests"?

If the folder containing tests isn’t named tests, the code in IntelliJ goes red. Is there a setting I need to set somewhere?

This is shown in the screenshot below, where the folder is called test rather than tests:

If I rename the folder from test to tests, the red code goes black as normal.

The screenshot above is just a cut down example, where renaming the folder to “tests” would obviously be an easy answer. However the reason I don’t want a folder called “tests” is because in a real solution the structure is a bit more complicated (it’s a Spring Boot app):

- src
  - main
    - kotlin
    - elm
  - test
    - kotlin
    - elm
      - <tests go here>

Note that I can run elm-test on a command-line and the tests run fine, regardless of the name of the folder.

[klazuka]

@yonigibbs I just merged the PR

[klazuka]

Source-direcctory hack

Let’s make it the user’s responsibility to add it to source-directories. Presumably they will have got things working from the command line already. And I would hope that as elm-test becomes more deeply integrated with Elm itself, they will make changes to the elm.json format to include a setting for test source dir.

However, there may be another way to handle this which has additional advantages. Right now the plugin shows a yellow banner at the top of the editor when it cannot find an associated ElmProject (elm.json) for the current .elm source file. And it gives the user the option to attach another elm.json file to the workspace to solve the problem. But in this case, the solution is not to attach but to add the containing directory as a source-directory to an existing ElmProject in the current workspace.

By taking this approach, we can solve this case as well as other cases (i.e. the user creates a vendor directory and moves some third-party Elm code into it but forgets to update source-directories). The downside might be that by suggesting it to the user, we might lead them down the wrong path in some cases. Wording would be important.

Duplicate test configs

Re-running the tests via the context menu (or ctrl-shift-r) should not re-create the run config. Maybe that’s a regression when the code was ported from Java to Kotlin. I just created an issue for it (#574).

Restricting tests to specific file(s)

Restricting the scope of tests based on context would be nice. I suspect that this would be a bit of work, so I would leave it out-of-scope for now. It looks like 0.18 elm-test only accepts a single file as a parameter, whereas 0.19 accepts multiple.