[GitHub] sruehl commented on issue #37: Extend test driver with mock
sruehl commented on issue #37: Extend test driver with mock URL: https://github.com/apache/incubator-plc4x/pull/37#issuecomment-435118195 @JulianFeinauer im confused as well. Is the test-protocol meant to be used from users of plc4x or within unit-tests in implementations using plc4x (kafka-connector, etc). Maybe we should add a README.MD to the test-protocol module to clear things up. IMHO when its meant to be used in our implementations (pool, opm) we should have something like that in test-utils or we could use that depending on what we would need from it. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: [GitHub] JulianFeinauer opened a new pull request #36: Add simple mock driver
Hi Chris,
sorry, I saw this too late.
I agree with your idea. And I think these Both would be good additions.
I already openend a PR for a "in-between" solution which allows to inject a
Mock Object where requests for Type "MOCK/..." are forwarded to.
This allows the Full power of frameworks like Mockito(times, timeouts,
ArgumentCapturing, ...), but we can open a Confluence or a Jira ISSUE to work
on a new 2.0 version.
Julian
Am 01.11.18, 17:57 schrieb "Christofer Dutz" :
Hi Julian,
Well maybe the ideal solution might be somewhere in between. How about us
adding a confluence page with features the test driver should have and then we
work on doing this.
I was thinking of adding more useable addresses to The test driver, sort of
like the simulated sensors in the Apache Edgent project.
Regarding assertions ... Shouldn't this also be possible by something like
this:
Address:
ASSERT/{value}:{type}
When writing to this address, it only works if you send the right data?
Or:
CONSTANT/{value}:{type}
So reading too just returns the value and type in the address?
Chris
Outlook for Android herunterladen
From: GitBox
Sent: Wednesday, October 31, 2018 10:30:45 PM
To: dev@plc4x.apache.org
Subject: [GitHub] JulianFeinauer opened a new pull request #36: Add simple
mock driver
JulianFeinauer opened a new pull request #36: Add simple mock driver
URL: https://github.com/apache/incubator-plc4x/pull/36
Hi all,
I wrote a simple Mock Driver implementation, as I need to do some
mocking for our application code.
To avoid conflicts I renamed the prefix of the current existing mock
driver (in core) to "spi-mock".
It would be good if someone checks over my changes to see if my changes
are okay.
Thanks!
Julian
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] JulianFeinauer opened a new pull request #37: Extend test driver with mock
JulianFeinauer opened a new pull request #37: Extend test driver with mock URL: https://github.com/apache/incubator-plc4x/pull/37 @chrisdutz here is my approach as extension to the Test Driver. @sruehl It is still not in the Test-utils package but I'm unsure if it should as I'm unsure about all the dependency mambo jambo. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: [GitHub] JulianFeinauer opened a new pull request #36: Add simple mock driver
Hi Julian,
Well maybe the ideal solution might be somewhere in between. How about us
adding a confluence page with features the test driver should have and then we
work on doing this.
I was thinking of adding more useable addresses to The test driver, sort of
like the simulated sensors in the Apache Edgent project.
Regarding assertions ... Shouldn't this also be possible by something like this:
Address:
ASSERT/{value}:{type}
When writing to this address, it only works if you send the right data?
Or:
CONSTANT/{value}:{type}
So reading too just returns the value and type in the address?
Chris
Outlook for Android herunterladen
From: GitBox
Sent: Wednesday, October 31, 2018 10:30:45 PM
To: dev@plc4x.apache.org
Subject: [GitHub] JulianFeinauer opened a new pull request #36: Add simple mock
driver
JulianFeinauer opened a new pull request #36: Add simple mock driver
URL: https://github.com/apache/incubator-plc4x/pull/36
Hi all,
I wrote a simple Mock Driver implementation, as I need to do some mocking
for our application code.
To avoid conflicts I renamed the prefix of the current existing mock driver
(in core) to "spi-mock".
It would be good if someone checks over my changes to see if my changes are
okay.
Thanks!
Julian
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] JulianFeinauer closed pull request #36: Add simple mock driver
JulianFeinauer closed pull request #36: Add simple mock driver URL: https://github.com/apache/incubator-plc4x/pull/36 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] JulianFeinauer commented on issue #36: Add simple mock driver
JulianFeinauer commented on issue #36: Add simple mock driver URL: https://github.com/apache/incubator-plc4x/pull/36#issuecomment-435101505 @chrisdutz I'll check if I can add this Mock functionality in there. As I recall the test driver is currently working against internal values or random values. But what I want is an object to put assertions on, so I'll check that and close this PR for the time beeing. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: Moving OPM Example
Hey Chris, I like Kittens also! And yes, I'm definitely okay and will prepare a documentation site soon to make it easier to adopt (well, I hope its pretty easy). Best Julian PS.: Kittens and Mallorca Am 01.11.18, 12:40 schrieb "Christofer Dutz" : Hi Julian, I am currently taking the liberty to move your HelloOpm example into a dedicated Maven module. … Great stuff by the way ☺ The reasoning behind this is, that the hello-plc4x should be as simple as possible. By splitting it up you can also lay emphasis on the OPM and even provide a README or whatsoever. Hope this is ok for you, Chris PS: Because Kittens (Promoting our Tag-Cloud to mention Kittens )
Moving OPM Example
Hi Julian, I am currently taking the liberty to move your HelloOpm example into a dedicated Maven module. … Great stuff by the way ☺ The reasoning behind this is, that the hello-plc4x should be as simple as possible. By splitting it up you can also lay emphasis on the OPM and even provide a README or whatsoever. Hope this is ok for you, Chris PS: Because Kittens (Promoting our Tag-Cloud to mention Kittens )
Re: Throw Exception when retrieving non-existing Field in Response
Hi,
thanks for your response.
I changed it.
Julian
Am 01.11.18, 12:30 schrieb "Christofer Dutz" :
Hi Julian,
I agree that we should throw an exception.
Chris
Am 31.10.18, 21:25 schrieb "Julian Feinauer" :
Hi all,
I found some time today to test and toy around a bit with PLC4X and I
discovered a behavior which I found weird.
I had the response from a request which “failed” (Response was
successful but the Field I wanted was NOT_FOUND).
So my response.getLong(“…”) returned a “null” and a subsequent implicit
cast to long finally led to a NPE.
My expected behavior would be an Exception (Runtime Exception).
Also in the case when I try to fetch a filed which is non-existent.
Currently we return null in both cases (see snippet from
DefaultPlcReadResponse):
private BaseDefaultFieldItem getFieldInternal(String name) {
// If this field doesn't exist, ignore it.
if (values.get(name) == null) {
return null;
}
if (values.get(name).getKey() != PlcResponseCode.OK) {
return null;
}
return values.get(name).getValue();
}
I suggest to throw a Runtime Exception in both cases to give a “valid”
Error Message instead of a NPE which is totally unexpected.
Is this okay for everybody? Or are there any concerns?
Julian
[GitHub] chrisdutz commented on issue #36: Add simple mock driver
chrisdutz commented on issue #36: Add simple mock driver URL: https://github.com/apache/incubator-plc4x/pull/36#issuecomment-435013325 I thought it would make more sense to start removing all of these mock drivers and instead extend the "Test-Driver" as this should provide everything that's needed. On the one side, we can use this internally for testing our integrations and examples. On the other side users can play around with PLC4X without having a real PLC. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: Throw Exception when retrieving non-existing Field in Response
Hi Julian,
I agree that we should throw an exception.
Chris
Am 31.10.18, 21:25 schrieb "Julian Feinauer" :
Hi all,
I found some time today to test and toy around a bit with PLC4X and I
discovered a behavior which I found weird.
I had the response from a request which “failed” (Response was successful
but the Field I wanted was NOT_FOUND).
So my response.getLong(“…”) returned a “null” and a subsequent implicit
cast to long finally led to a NPE.
My expected behavior would be an Exception (Runtime Exception).
Also in the case when I try to fetch a filed which is non-existent.
Currently we return null in both cases (see snippet from
DefaultPlcReadResponse):
private BaseDefaultFieldItem getFieldInternal(String name) {
// If this field doesn't exist, ignore it.
if (values.get(name) == null) {
return null;
}
if (values.get(name).getKey() != PlcResponseCode.OK) {
return null;
}
return values.get(name).getValue();
}
I suggest to throw a Runtime Exception in both cases to give a “valid”
Error Message instead of a NPE which is totally unexpected.
Is this okay for everybody? Or are there any concerns?
Julian
