Kratos: compilation of a testing exe

[RiccardoRossi]

@roigcarlo i think it would be better to create a testing library (complete with a python interface) AND an exe file for the tests. This way the KratosCore would not depend on the tests, but the tests might depend on the kratoscore.

i think this would imply doing something like the following in the CMakeLists

if(${KRATOS_BUILD_TESTING} MATCHES ON)
file(GLOB_RECURSE KRATOS_TESTING_SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/tests/*.cpp)
add_library(KratosTests ${KRATOS_CORE_TESTING_SOURCES})
add_executable(KratosTesting ${CMAKE_CURRENT_SOURCE_DIR}/testing_main.cpp)
target_link_libraries(KratosTesting KratosCore)
endif(${KRATOS_BUILD_TESTING} MATCHES ON)

[roigcarlo]

I like the idea of decoupling the tests from the core :+1:

About the executable file, no problem as well but I have some concerns:

• I recall @pooyan-dadvand telling me he doesn't want C++ executable files ( or I am making it up? sorry my memory... )
• How should this behave? If we are going to make it something "official" we must speak about some topics such as:
  
  
  
  • Is it going to be an interactive command line to run the tests?
  
  
  • Run all the tests without asking the user?
  
  
  • Should we be able to pass arguments?
  
  

[pooyan-dadvand]

• actually I like to have a direct executable for cpp tests because it makes the debugging and especially profiling much easier

• some command line ese which accepts arguments to define tests or suits would be enough

[pooyan-dadvand]

Technical committee: The idea is to create a CTest executable for core and each application

[loumalouomega]

Will be compatible with CDash?

https://cmake.org/related-software/

El mié., 27 jun. 2018 12:40, Pooyan Dadvand [e-mail]
escribió:

Technical committee: The idea is to create a CTest executable for core and
each application

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/83#issuecomment-400627955,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATEMgCMlKVTdmiRysHKwLJ9vTXcz9B1Iks5uA2ElgaJpZM4MM5Oi
.

[pooyan-dadvand]

It should

[loumalouomega]

Can we consider this as solved?, or not until we add the CTest compatibilty?

[roigcarlo]

It is not solved, tests are still compiled as part of the owner application.

I tried to split it in the past abd it gave me some problems in win, but I am pretty confident in being able to do it now. I can spend some time to it next week.

[philbucher]

if the tests are in a separate exe then we also won't have to link the entire Kratos again after changing a test in the core right?

[roigcarlo]

As a side effect. My idea is not only create a separate binary but also a separate lib with the tests. so te core will have:

• KratosCore.so
• Kratos.so ( depends on KratosCore )
• KratosTests.so ( depends on KratosCore )
• RunKratos
• RunTests ( depends on KratosTests.so )

Also the proble with the link times is the LTO, we have been running some tests last week and we will probably reove it.

[philbucher]

any news here?

[roigcarlo]

Actually its almost ready, I will probalby make a commit with this next week

[roigcarlo]

So, the skeleton its done, and it works:
https://github.com/KratosMultiphysics/Kratos/tree/testing/split-core-tests

There are some of the points I wanted to do that are completed (For the core):

• [x] Creating a separate lib with the tests
• [x] Creating a separate entry point for the test in python (its a submodule of the app now)
• [x] Creating a executable that wrapps the functions of the tester class (right now only RunAllTests() for test purposes)

As for the apps, there are some problems.

• If we link the test library against the core executable, the application is not registered and there are a bunch of elements, conditions, variables, etc... that are missing, causing the tests from the app not working
• We can register the app, but that means that the code of the testes has to be aware of all existing apps having cpp tests, which I think is not ideal
• Alternatively, if we make one executable per app, it has to be hard-coded so it register the app it tries to run, which requires maintenance, so it is also something that I don't like.

I know that we decide to create one separate binary for every app but that was mainly because I said it was impossible to create a unified binary, which is actually possible and very easy, so what do you think we should do with the current situation?

[philbucher]

Nice job :+1:

I am not really familiar with the details but I have a possibly related comment regarding the usage of the C-tests:

I am currently trying to solve the problems I introduced in #3007 => there I import all apps and then run the tests, but as already mentioned here it would be better to run the tests in AssembleTestSuites in test_xxxAPplication.py
Long story short, from this point of view it would be nice to be able to run the tests of only one app, not sure if it is related to this though (maybe easier if we have separate libs for the tests of each app), if not sorry for the noise