[GH-ISSUE #586] The state of the tests? #458

Closed
opened 2026-05-05 06:27:30 -06:00 by gitea-mirror · 4 comments
Owner

Originally created by @chewi on GitHub (Mar 10, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/586

You may have noticed a large suite of tests lurking within your code base. 😛 These have basically been left untouched since the fork. They were inadvertently disabled before that in 688095d0a7. It's odd that this was never fixed. Synergy still hasn't corrected it. As you've probably guessed, they don't even build, let alone pass. There's even a big merge conflict in one of the files that arose during the fork.

Given the state of these, I strongly suggest you drop the bundled and outdated copy of gmock+gtest. Even if the tests were to be reinstated, it is better practise to source this framework externally. All it's doing right now is massively bloating your source tarballs.

Originally created by @chewi on GitHub (Mar 10, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/586 You may have noticed a large suite of tests lurking within your code base. :stuck_out_tongue: These have basically been left untouched since the fork. They were inadvertently disabled before that in 688095d0a7d22704b5c3282bc68b41ceca42ab7e. It's odd that this was never fixed. Synergy still hasn't corrected it. As you've probably guessed, they don't even build, let alone pass. There's even a big merge conflict in one of the files that arose during the fork. Given the state of these, I strongly suggest you drop the bundled and outdated copy of gmock+gtest. Even if the tests were to be reinstated, it is better practise to source this framework externally. All it's doing right now is massively bloating your source tarballs.
gitea-mirror 2026-05-05 06:27:30 -06:00
Author
Owner

@walker0643 commented on GitHub (Mar 11, 2020):

@chewi - Thanks for bringing this to our attention. Here's what I found while looking in to the issue:

  • Looking at the linked commit I do believe that the tests were removed from the build by mistake. It's odd indeed that no one ever noticed 😕

  • I don't know if I agree that they are "massively bloating" the tarballs. Uncompressed our tests directory and the google testing framework only eats about 10MB.

  • I got the tests up and running without much effort. The framework needed an update and our tests subdir needed some TLC.

  • Curently on my dev machine all but one of the tests are passing.

I have created a testing-framework branch for our devs to use to determine the value of the current tests. I'm hoping they can be useful, but we'll see how it goes. Thanks again for bringing this up!

@debauchee/barrier-developers - Please test the testing-framework branch at your convenience. Add -DCMAKE_BUILD_TESTS=1 as a param to cmake to enable building tests. Thanks!

<!-- gh-comment-id:597689009 --> @walker0643 commented on GitHub (Mar 11, 2020): @chewi - Thanks for bringing this to our attention. Here's what I found while looking in to the issue: - Looking at the linked commit I do believe that the tests were removed from the build by mistake. It's odd indeed that no one ever noticed 😕 - I don't know if I agree that they are "massively bloating" the tarballs. Uncompressed our tests directory and the google testing framework only eats about 10MB. - I got the tests up and running without much effort. The framework needed an update and our tests subdir needed some TLC. - Curently on my dev machine all but one of the tests are passing. I have created a testing-framework branch for our devs to use to determine the value of the current tests. I'm hoping they can be useful, but we'll see how it goes. Thanks again for bringing this up! @debauchee/barrier-developers - Please test the testing-framework branch at your convenience. Add -DCMAKE_BUILD_TESTS=1 as a param to cmake to enable building tests. Thanks!
Author
Owner

@chewi commented on GitHub (Mar 11, 2020):

I don't know if I agree that they are "massively bloating" the tarballs. Uncompressed our tests directory and the google testing framework only eats about 10MB.

My first hard drive was 20MB and I'm somewhat old fashioned so 10MB still feels like a lot to me. 😛 For what it's worth, dropping it reduces the source tarball from 7.0MB to 5.3MB. I must admit I thought it would be bigger reduction. With the tests working again, at least it's there for a reason.

However, I partly made the point because I've packaged this for Gentoo Linux and we want to be able to run the tests without using a bundled copy of GTest. I will therefore be submitting a patch to allow that. I don't know why you'd want to build it each time either?

<!-- gh-comment-id:597842520 --> @chewi commented on GitHub (Mar 11, 2020): > I don't know if I agree that they are "massively bloating" the tarballs. Uncompressed our tests directory and the google testing framework only eats about 10MB. My first hard drive was 20MB and I'm somewhat old fashioned so 10MB still feels like a lot to me. :stuck_out_tongue: For what it's worth, dropping it reduces the source tarball from 7.0MB to 5.3MB. I must admit I thought it would be bigger reduction. With the tests working again, at least it's there for a reason. However, I partly made the point because I've packaged this for Gentoo Linux and we want to be able to run the tests without using a bundled copy of GTest. I will therefore be submitting a patch to allow that. I don't know why you'd want to build it each time either?
Author
Owner

@walker0643 commented on GitHub (Mar 11, 2020):

You're absolutely welcome to submit any patch that does so. My quick and dirty solution was a minimal update just to get tests working so that we could discuss how to integrate them into our workflow. Also, tests should not be building by default. You should have to set the CMAKE_BUILD_TESTS flag...otherwise they are ignored entirely as per usual.

<!-- gh-comment-id:597854566 --> @walker0643 commented on GitHub (Mar 11, 2020): You're absolutely welcome to submit any patch that does so. My quick and dirty solution was a minimal update just to get tests working so that we could discuss how to integrate them into our workflow. Also, tests should not be building by default. You should have to set the CMAKE_BUILD_TESTS flag...otherwise they are ignored entirely as per usual.
Author
Owner

@p12tic commented on GitHub (Aug 22, 2020):

As of current master, the unit and integration tests work, but are not enabled by default.

<!-- gh-comment-id:678624868 --> @p12tic commented on GitHub (Aug 22, 2020): As of current master, the unit and integration tests work, but are not enabled by default.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#458
No description provided.