Skip to content

Conversation

@FrogTheFrog
Copy link
Contributor

Description

Implemented the first topology methods, yay!

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Dependency update (updates to dependencies)
  • Documentation update (changes to documentation)
  • Repository update (changes to repository files, e.g. .github/...)

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

  • I want maintainers to keep my branch updated

@codecov
Copy link

codecov bot commented May 7, 2024

Codecov Report

Attention: Patch coverage is 88.23529% with 10 lines in your changes are missing coverage. Please review.

Project coverage is 74.87%. Comparing base (c791085) to head (df4202a).

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #24      +/-   ##
==========================================
+ Coverage   69.25%   74.87%   +5.61%     
==========================================
  Files           6       11       +5     
  Lines         309      394      +85     
  Branches      177      221      +44     
==========================================
+ Hits          214      295      +81     
+ Misses         39       38       -1     
- Partials       56       61       +5     
Flag Coverage Δ
Linux 78.72% <ø> (ø)
Windows 75.86% <88.23%> (+5.65%) ⬆️
macOS 51.66% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
src/windows/include/displaydevice/windows/types.h 100.00% <100.00%> (ø)
src/windows/winapilayer.cpp 71.19% <ø> (+2.46%) ⬆️
src/windows/windisplaydevicegeneral.cpp 100.00% <100.00%> (ø)
...s/include/displaydevice/windows/windisplaydevice.h 0.00% <0.00%> (ø)
src/windows/winutils.cpp 92.30% <92.30%> (ø)
src/windows/windisplaydevicetopology.cpp 84.61% <84.61%> (ø)

... and 1 file with indirect coverage changes

@FrogTheFrog FrogTheFrog force-pushed the master branch 4 times, most recently from e2a5fe4 to 5cebfb8 Compare May 8, 2024 13:34
// local includes
#include "mockwinapilayer.h"

namespace {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not familiar with gmock, but is there a way to parametrize these?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow? I have defined these const's to be reusable within the first UT and future UTs.

Copy link
Contributor Author

@FrogTheFrog FrogTheFrog May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you meant TEST_P, I have decided against it, since it requires it's own test fixture and the data set is just too small where it is usable to justify creating for a single function.

In other places the EXPECT_CALL is too different for most cases, so it would be hard to parametrize it properly.

@ReenigneArcher
Copy link
Member

I've fixed the issue with coverage in the ci. You can revert your last commit (also not sure we need the _deps or not).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants