Closed nickolas-deboom closed 1 week ago
Channel deleted.
64 files 401 suites 0s ⏱️ 1 999 tests 1 999 ✅ 0 💤 0 ❌ 3 439 runs 3 439 ✅ 0 💤 0 ❌
Results for commit d14d4570.
:recycle: This comment has been updated with latest results.
File | Coverage | |
---|---|---|
All files | 94% |
:white_check_mark: |
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/init.lua | 96% |
:white_check_mark: |
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/eve-energy/init.lua | 91% |
:white_check_mark: |
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/aqara-cube/init.lua | 96% |
:white_check_mark: |
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/matter-switch/src/embedded-cluster-utils.lua | 38% |
:x: |
Minimum allowed coverage is 90%
Generated by :monkey: cobertura-action against d14d45709c75a17705d13e3e4f6a5c71966553f6
Just a reminder to rebase as well so that the latest changes are present and so that unit tests can run :)
Done!
One thing we will want to do before merging these changes is complete a set of regression tests for the various device types that share this driver since we are touching a critical code path. I think you could potentially add the test cases to the great confluence page you already put together, listing which cases are covered by unit tests and real devices, or both: https://smartthings.atlassian.net/wiki/spaces/~7120201ec2fa4a1b0548dd86df78b89d08422e/pages/3449815291/Supporting+Combination+Button+Switch+Devices#Testing.
Let's think of some device compositions that are commonly used and also add in some that might be corner cases. For example:
A good chunk of these are already covered by existing unit tests and the ones you have added, I just wanted to list all the ones I could think of to be complete. Where we can, we should do smoke testing with real devices in addition to the unit tests. Some of these will be impossible to test with real devices (test 8 for example, I'm not sure we have a real device like that), so they can be covered by a unit test case (which it looks like you've already done for test 8). If you can think of any more edge cases, please add them!
One thing we will want to do before merging these changes is complete a set of regression tests for the various device types that share this driver since we are touching a critical code path. I think you could potentially add the test cases to the great confluence page you already put together, listing which cases are covered by unit tests and real devices, or both: https://smartthings.atlassian.net/wiki/spaces/~7120201ec2fa4a1b0548dd86df78b89d08422e/pages/3449815291/Supporting+Combination+Button+Switch+Devices#Testing.
Let's think of some device compositions that are commonly used and also add in some that might be corner cases. For example:
1. Single switch device (bulb, plug, etc.) 2. Single button device 3. Multi-switch only device 4. Multi-button only device 5. Switch/Button combo device with a single switch and multiple buttons 6. Switch/Button combo with a multiple switches and a single button 7. Switch/Button combo with multiple switches and multiple buttons 8. Switch/Button combo with multiple switches and multiple buttons where the switch has lower endpoints than the buttons
A good chunk of these are already covered by existing unit tests and the ones you have added, I just wanted to list all the ones I could think of to be complete. Where we can, we should do smoke testing with real devices in addition to the unit tests. Some of these will be impossible to test with real devices (test 8 for example, I'm not sure we have a real device like that), so they can be covered by a unit test case (which it looks like you've already done for test 8). If you can think of any more edge cases, please add them!
Good point! I added section Test coverage for other device compositions to the confluence page. I created a table with the endpoint configurations you listed and linked to the test case files that cover each configuration. I tested out a few cases with physical devices I have, and I also expanded test_matter_multi_button_child_switch.lua
to include test cases to cover cases 5, 7, and 8. Please let me know if you think there is anything else I should add!
Duplicate profile check: Passed - no duplicate profiles detected.
I think this confluence page needs to be updated with the latest screenshots with the new component layout: Test coverage for other device compositions
I would also note on that page what switch/button combos are supported, and what expected behavior is for an unsupported combination device.
Also, I think another round of device regression testing might be good to verify the latest changes with the new layout. Fortunately, a lot of this is covered with unit tests, so good job on that test coverage!
I think this confluence page needs to be updated with the latest screenshots with the new component layout: Test coverage for other device compositions
I would also note on that page what switch/button combos are supported, and what expected behavior is for an unsupported combination device.
Also, I think another round of device regression testing might be good to verify the latest changes with the new layout. Fortunately, a lot of this is covered with unit tests, so good job on that test coverage!
I updated the confluence page with new details about testing, for both the Inovelli and the GE/Cync device. I added some notes on what the behavior would be for unsupported device types as well in the Testing section.
Few minor comments but otherwise looks good to me. Need to make sure to do a thorough regression test with devices that would use the affected code paths.
I did regression testing on all of the devices listed on this page, which includes lights, plugs, and buttons as well as the GE/Cync and Inovelli switch/button combo devices. I also created unit tests to verify the functionality for a device that would join a MCD profile containing switch and button components as well as a device that has button endpoints and a switch endpoint that would not be supported by a MCD profile and uses parent-child for the switch endpoint instead.
Type of Change
Checklist
Description of Change
CHAD-13993
This change adds support for devices that contain both switch and button endpoints. The button driver was initially merged into the driver in PR 1547, but until now only pure-button and pure-switch devices were supported.
The first switch endpoint and all button endpoints will join as a multi-component device, and additional switch endpoints will join as child devices.
The GE/Cync dimmer/keypad is an example of a device that is supported by this change.
Summary of Completed Tests
See new unit tests and also here for an overview of testing. Additional regression testing is documented here.