Discussion of unit test format

[Alex0vSky]

For #25.
The location of the test files is perhaps the most unclear point:

• test/*;
• tests/*;
• qa/UnitTest/*, qa=QualityAssurance, this is in case tests are not enough and the rest of the staff can be placed nearby.

Do we need to keep the test run file in one separate main.cpp file?

To run a CI on GitHubAction, we need to upload the gtest+gmock files to the repository. Is the ThirdParty directory suitable?

Glad that the most boring part in the from0ToMax.cpp file is completed. It's in the commit.

[Alex0vSky]

Here gtest+gmock files in the directory qa/UnitTest/* for example, new commit 976f12f
63 new files...

[Alex0vSky]

Here is a combinations table of possible build configurations.

Toolset	MSVC	LLVM
Arch	x86	x64
Debug	_DEBUG	nope
Optimization	/Od	/GL /O2(/Ox) /LTCG
C++ Version	/std:c++14	/std:c++17	/std:c++20	/std:c++23

Calculation: wolframalpha
Combinatorics in LaTeX: ${1 \choose 2} \times {1 \choose 2} \times {1 \choose 2} \times {1 \choose 2} \times {1 \choose 4} = 64$
There are a total of 64 configuration options.

We have 2'000 free GitHubAction CI minutes per month, that should probably be enough, interesting.
https://github.com/settings/billing

[smalti]

Hi, thanks for starting the unit testing discussion,

For #25. The location of the test files is perhaps the most unclear point.

I think, the test* / tests/* will be a good place for them.

Do we need to keep the test run file in one separate main.cpp file?

Let's initiate our work with main.cpp, and we'll make further improvements as more tests become available.

To run a CI on GitHubAction, we need to upload the gtest+gmock files to the repository. Is the ThirdParty directory suitable?

Have you considered using git submodules as an alternative to storing files directly in the repository? We might need to script the submodule checkout process. I've seen this method in use, for example, at https://github.com/apriorit/gmock-global-sample. Additionally, there's useful information about integrating GitHub Actions with git submodules at https://tommoa.me/blog/github-auto-update-submodules/. We should also ensure compatibility with specific versions of gtest-lib, such as the latest one that we support.

Glad that the most boring part in the from0ToMax.cpp file is completed. It's in the commit.

Good initial unit-tests commit!

[Alex0vSky]

Accepted.

Have you considered using git submodules as an alternative to storing files directly in the repository? ... We should also ensure compatibility with specific versions of gtest-lib, such as the latest one that we support.

Now I-ve read a bit about submodules. Looked at what they look like in Github https://github.com/apriorit/gmock-global-sample/tree/master/src/3rd-party. Is there a difference between downloading releases of a given version gtest+gmock in CI or having git submodules? The difference is in the further development process.

[smalti]

Now I-ve read a bit about submodules. Looked at what they look like in Github https://github.com/apriorit/gmock-global-sample/tree/master/src/3rd-party. Is there a difference between downloading releases of a given version gtest+gmock in CI or having git submodules? The difference is in the further development process.

I don't know what the actual difference will be. Maybe we should support the latest version (instead of the fixed library version tag) of gtest+gmock, and as a result, we should point to the main of this lib. What do you think?

[Alex0vSky]

I basically figured out what I wanted and am ready to make a decision. Workflow CI will make a clone of the "latest" version of gtest/gmock.

I don't know what the actual difference will be.

I refuse "submodules" due to negative community reviews about this technology, I heeded the warning.

• The advantage is that the "ThirdParty" repo directory will not contain code that is not related to the project.
• The disadvantages are that CI time will be wasted on cloning a third-party repo, but this is not so bad because GitHubAction has caching.

... we should point to the main of this lib ...

Arguments for our own "main":

• Just recently we had doubts about "AppCompat/ShimDLLs". This case should be one of the first test cases; if there is a bug, all other tests will not work. Obviously, it's better to use only "Main" to put the tests in the right order.
• It’s better to initialize the library in "Main" too.

For now, I suggest leaving this thread open, at least until the first CI commit merge.

[smalti]

I basically figured out what I wanted and am ready to make a decision. Workflow CI will make a clone of the "latest" version of gtest/gmock.

I don't know what the actual difference will be.

I refuse "submodules" due to negative community reviews about this technology, I heeded the warning.

• The advantage is that the "ThirdParty" repo directory will not contain code that is not related to the project.
• The disadvantages are that CI time will be wasted on cloning a third-party repo, but this is not so bad because GitHubAction has caching.

... we should point to the main of this lib ...

Arguments for our own "main":

• Just recently we had doubts about "AppCompat/ShimDLLs". This case should be one of the first test cases; if there is a bug, all other tests will not work. Obviously, it's better to use only "Main" to put the tests in the right order.
• It’s better to initialize the library in "Main" too.

For now, I suggest leaving this thread open, at least until the first CI commit merge.

I think we could start with any approach, and we can always improve it later if we need it.

[Alex0vSky]

Closed due to success.

We have reached a common opinion and there is no negative reaction to the first results of CI over time.