Gtests01

[ingo-h]

Make gtests running with new user interface

[Vollstrecker]

Short summary: Looks OK.

Longer version:

• I guess they still don't compile on Win, so they should be wrapped in if (NOT WIN32)

• I still don't get the sense of compile.sh, they are linked to the lib, and in the process of creating that they are created, too. Sure, for a quick code-change this could help, But just make is still shorter.

• For what is this test_template meant, that does nothing and isn't even compiled?

• I still prefer to mark the failing test and run them anyway. First: Just because noone would have to remember them as I always guess that if this stuff is not addressed with the next few weeks, it will be just forgotten. Second: If this is fixed as a side-effekt of something completely different, you'll notice, and third: The WILL_FAIL flag in the shorter CMakeLists.txt is easier to find and change. But wrapping in a nice function to mark 2 out of 5(?) will be a funktion that needs it's own handbook. Easiest would be to split out the failing ones into an separate source, but I guess this will bring some more common func's and headers, and it's not worth the work for a tempory fix.

Oh, and I still wonder why they don't appear in the tests here.

[ingo-h]

• I still don't get the sense of compile.sh, they are linked to the lib, and in the process of creating that they are created, too. Sure, for a quick code-change this could help, But just make is still shorter.

It is three times faster. I manly use it for the tools and have moved it to that directory.

• For what is this test_template meant, that does nothing and isn't even compiled?

It is a template for new tests and it is a quick check if googletest works. It is a test of the testsystem. Developer just starting with gtests can look at it as entry point. No problem to have it compile and run on every sanity check.

• I still prefer to mark the failing test and run them anyway.

Already done yesterday but was removed from gtest/CMakeLists.txt. Will put it back soon after troubleshooting for tests with mocked functions. That are the only tests that fail but not on all tests. Detailed documentation of disabled tests is done on every test output.

Oh, and I still wonder why they don't appear in the tests here.

Don't know who has them removed.

[Vollstrecker]

Don't know who has them removed.

We have added meanwhile another check. At least in the file I see here, the check executed is not yours.

[mrjimenez]

• I still don't get the sense of compile.sh, they are linked to the lib, and in the process of creating that they are created, too. Sure, for a quick code-change this could help, But just make is still shorter.

It is three times faster. I manly use it for the tools and have moved it to that directory.

It is ok to have tools that makes developer's lives easier. Add some comments to compile.sh explaining that.

• For what is this test_template meant, that does nothing and isn't even compiled?

It is a template for new tests and it is a quick check if googletest works. It is a test of the testsystem. Developer just starting with gtests can look at it as entry point. No problem to have it compile and run on every sanity check.

Well, then make it be compiled. I am not against it, but please do clearly state the objective in the comments.

• I still prefer to mark the failing test and run them anyway.

Already done yesterday but was removed from gtest/CMakeLists.txt. Will put it back soon after troubleshooting for tests with mocked functions. That are the only tests that fail but not on all tests. Detailed documentation of disabled tests is done on every test output.

I am having some difficulty in understanding what exactly you are talking about. There are two kinds of test:

1. Those that have already succeeded and now are part of sanity checking.
2. Those that have never succeeded and are part of the development of new features or for fixing old wrong functionality.

Tests in the first category are the ones that must be run on Github actions. Tests in the second category must have a way to be run outside github actions.

Oh, and I still wonder why they don't appear in the tests here.

Don't know who has them removed.

Also don't understand what you are saying. The commits are all in this page.

Oh, another thing. I am getting this message: "This branch cannot be rebased due to conflicts". The conflicts are in the files CMakeLists.txt. They all leave the files unusable. E.g.:

<<<<<<< HEAD
    find_package (GTest CONFIG)

    if (GTest_FOUND)
        add_subdirectory (gtest)
    elseif (DOWNLOAD_AND_BUILD_DEPS AND NOT GTest_FOUND)
        CmDaB_install (googletest)
        add_subdirectory (gtest)
=======
#   if (NOT WIN32)
        find_package (GTest CONFIG)

        if (GTest_FOUND)
            add_subdirectory (gtest)
        elseif (DOWNLOAD_AND_BUILD_DEPS AND NOT GTest_FOUND)
            CmDaB_install (googletest)
            add_subdirectory (gtest)
        endif()
>>>>>>> 0ec135f (Include gtest/)

Either one of you must do the rebase by hand, or you must tell me what to do, since I am not the best person to deal with this stuff. I would prefer the former, but I can do that if you think it is too clumsy. I understand, it is clumsy and it took me some time to get used to it. The command is:

git rebase master ingo-h-gtests01

From then on, just follow git's instructions. If you need help, please call me.

[mrjimenez]

This is the second conflict (gtest/CMakeLists.txt):

<<<<<<< HEAD
=======
addGTest (test_upnpapi test_upnpapi.cpp
    ADDITIONAL_INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/../upnp/src/threadutil/
)

>>>>>>> 0564913 (Make gtests running with new user interface)
addGTest(test_UpnpHttpHeaderList test_UpnpHttpHeaderList.cpp
    ADDITIONAL_INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/../upnp/src/threadutil/
)

[mrjimenez]

Well, I did my best and this is what came out: #305 .

If there are changes to be made, please do on top of this branch so that we can merge it using Github tools.

Lets continue on the other thread.