As developer, I can run a test suite through gradle that contains unit and/or integration tests for all major features, so that I have examples for how the project should be used and can quickly find bugs that I introduced.

[CptKaNe]

I can't remember where I have heard this tip, but i find that a good guideline is that each unit test should be a hypothesis about errors in your code. Something like "function f will fail, if I call it with a list that is not fully sorted as its first parameter". You should be able to formulate such a hypothesis as a short sentence for each test you write and actually write that hypothesis down as a comment in the test code. This will help you to define meaningful test cases and to quickly identify which new hypotheses you haven't covered yet.

Suggested test hypotheses:

• Mo|E will fail to report non-existing top-level classes.
• Mo|E will fail to report a non-existing class within an existing top-level class.
• Mo|E will fail to report the use of a variable that was never defined.
• The Mo|E server process will not shut down when it receives a shutdown request.
• When two instances of the Mo|E server are started and initialized on the same machine, they will share an OMC instance.(Which may lead to unexpected behavior)
• ... and many more regarding much more fine-grained issues within single methods in the code.

[CptKaNe]

In fact, I started to implement basic tests(MopeSWTP-SS21/LspConsole@027cf13cade3cf97862bd79cc520135beb335ef0) , which are not based on error hypothesis, but testing the expected responses of the server to several clientrequests. However that's not the problem, as I obviously could flip these tests so that they are based on an error hypothesis or simply add new tests based on this logic.

The problem with the current tests is all about the path thing. Locally, every test works fine, as the pathing is of course correct on the local machine. As expected, the triggered build on Github Actions (MopeSWTP-SS21/LspConsole@b5964fb4005b7eb40a308f92946298ee4a61575d) fails on every test where a path is included. Actually, i got no real clue on solving this mismatch expect rewriting the tests on your described error hypothesis logic, i.e "Mope will fail to add a non existing folder to its path" instead of checking the correctness of the folderpath.

Or is there a possibility to choose a path, our github actions build can handle?

[manuEbg]

What do you mean by "Path Thing" ?:)

I think the Modelica Path that is returned in the first Test of our GitHubAction looks good. The only problem is that the User who is starting the omc is now called runner and not swtp.... so maybe its possible to replace this part of the Testresult with a function that returns the executing User?

[manuEbg]

The Load Model Test fails because this path /home/swtp/modelica/exampleModels does not exist. So I would

• replace the above Path with something like /home/{executingUser}/modelica/exampleModels
• You need to add the exampleModels to the Agent that is running our action. To do so i would:
  1. add a Task that clones this repo https://github.com/THM-MoTE/ModelicaScriptingTools.jl
  2. add a Task that copies the ExampleModels to /home/{executingUser}/modelica/exampleModels

[CSchoel]

Just my 2 cents: You should never depend on any paths outside the repository - period. This implies that you should never use any absolute paths (starting with / or on windows C:\) at all. Why not include the example models in the repo and use a relative path? If you do not want the examples in the repo, you can download them via an action from some other source.

[manuEbg]

Just my 2 cents: You should never depend on any paths outside the repository - period. This implies that you should never use any absolute paths (starting with / or on windows C:\) at all. Why not include the example models in the repo and use a relative path? If you do not want the examples in the repo, you can download them via an action from some other source.

Yeah this is good because it allows people who clone the repo, to run the tests:)

Edit: In case they have omc installed:)

[CptKaNe]

Today i refactored the code so it should be user independent for now. Copy the exampleModels via an action is more difficult for me. i guess the right track is something like described here:

https://www.inmotionhosting.com/support/website/git/deploy-files-github-actions/

but i did not managed it yet. maybe we should have a look together on this one @manuEbg.

due to that i forgot to change the remote to the main repo of our organization, so the commit for now is in the lspconsole repo, i will change it later on or tomorrow.

[manuEbg]

Why not include the example models in the repo and use a relative path?

@CptKaNe I think this would make Life a lot easier:) Or you could create a new Repo full of ExampleModels and just clone that Repo during our Action

[CSchoel]

Even if you do not copy the models into the repo (which is totally fine, since they are part of a project of mine that is also MIT licensed), there would be easier ways:

# Option 1: Clone repo containing the example models (good idea for full projects like hh-modelica)
# Note: Use https instead of ssh (git@github.com:...) in order to avoid the need for authentication
git clone https://github.com/CSchoel/hh-modelica.git

# Option 2: Just use wget to get the single files that you need (good for small self-contained files)
wget https://raw.githubusercontent.com/THM-MoTE/ModelicaScriptingTools.jl/main/test/res/ArithmeticError.mo
# Note: You can also use this to get tagged releases of larger repos as zip file
wget https://github.com/CSchoel/hh-modelica/archive/refs/tags/v1.1.0.zip
unzip v1.1.0.zip

[CptKaNe]

due to several issues last week concerning my health i was not able to work on any issue. I just arrived from the medic and will put my effort in the issues the remaining four days. i am sorry about that.