-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[knx] Add integration tests #15727
[knx] Add integration tests #15727
Conversation
Maybe we can test both at once and return the send frame as incoming frame from the bus? |
b8a26ca
to
b94edca
Compare
Exactly. Now a CEMI frame is generated from the data, which is used to send an indication to all listeners. A Concept is working, test for 251.600 is there. PR needs some generalization and other data types to be covered. |
b94edca
to
2b0cc15
Compare
Generalization to other DPTs is done, tests for different DPTs have been added. |
73527c2
to
f36d2ed
Compare
Cleaned up the commit history, as this should not be squashed during merge. |
f36d2ed
to
dfc8997
Compare
dfc8997
to
95ea7c6
Compare
* Add integration tests which include decoding and encoding KNX frames, and the handling by Calimero library as well. This ensures that the KNX wire format is handled properly. * Add itests for DPT1 and color DPTs 251.600 and 232.600. Signed-off-by: Holger Friedrich <[email protected]>
- Change default type of DPT14 to QuantityType - Allow for parsing DPT20, DPT21, DPT22 as DecimalType in addition to String - Add DPTs for color transitions, mapped to String: DPT243.600, DPT249.600, DPT250.600, DPT252.600, DPT253.600, DPT254.600 - Adapt handling of DST flag in DPT19.001 Signed-off-by: Holger Friedrich <[email protected]>
95ea7c6
to
534f593
Compare
Fixed a few typos in the code comments. Ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general looks good an very useful.
...org.openhab.binding.knx/src/main/java/org/openhab/binding/knx/internal/dpt/ValueDecoder.java
Outdated
Show resolved
Hide resolved
...openhab.binding.knx/src/test/java/org/openhab/binding/knx/internal/itests/Back2BackTest.java
Show resolved
Hide resolved
import tuwien.auto.calimero.process.ProcessCommunicatorImpl; | ||
|
||
/** | ||
* Integration test to check conversion from raw KNX frame data to OH data types and back. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not an integration test in the sense we usually use it in the openHAB context. We call a test an integration test if it starts the whole framework and executes tests in a running application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that as well. Looking from the perspective of the binding code, it is more than a unit test, as we involve the full Calimero stack. How would you call it? Back2Back? E2E? Though, E2E is typically considered even more as integration test....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@J-N-K Do you have a proposal? Or should we merge as it is?
…ing/knx/internal/dpt/ValueDecoder.java Co-authored-by: J-N-K <[email protected]> Signed-off-by: Holger Friedrich <[email protected]>
@kaikreuzer I would like to see this in the next milestone build if possible. It should be merged as 2 separate commits to keep the records. I think we have only one open point above: can we call this an integration test or shall I change the naming to something different.... WDYT? |
I'll leave merging this to @J-N-K as he already did the initial review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say that the benefit of having these tests outweigh any potential confusion due to the naming. Since no-one seems to have a better proposal, we should merge as-is.
thank you! |
* [knx] Add integration tests * [knx] Adapt handling of DPTs Signed-off-by: Holger Friedrich <[email protected]> Signed-off-by: Jørgen Austvik <[email protected]>
* [knx] Add integration tests * [knx] Adapt handling of DPTs Signed-off-by: Holger Friedrich <[email protected]>
The idea of this PR is basically to check the whole way from bytes on the KNX bus through Calimero, into the plugin, and back again via Calimero down to the bus again. The implementation overwrites KNXNetworkLink to implement a test interface. Calimero is then set up on top.
The benefit of this approach is that we now cover large parts of the handling of KNX frame in the Calimero library, without the need of setting up real itests including bus communication to mimic the KNX communication.
PR is ready for review, tests for more DPT subtypes can be added later.