mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 22:01:23 -06:00
[GH-ISSUE #586] The state of the tests? #458
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#458
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
@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!
@chewi commented on GitHub (Mar 11, 2020):
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?
@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.
@p12tic commented on GitHub (Aug 22, 2020):
As of current master, the unit and integration tests work, but are not enabled by default.