Closed suhlig closed 1 year ago
Hi @suhlig, excuse me for the long reply. Unfortunately, I missed your issue/message in my mailbox.
I like your idea and I'm not against adding the interface class to this source code. But I'm not so happy with your proposed solution (rename class Servo
to ServoESP32
) as this solution is breaking compatibility.
What are your arguments against creating IServo
interface class for the current Servo
class? Or what advantages you would get with renaming Servo
class to ServoESP32
?
rename class Servo to ServoESP32 [...] is breaking compatibility.
Yeah, that's what I guessed. I don't think the proposed change would be valuable enough to warrant breaking compatibility.
As for Servo
vs. IServo
, it might be a matter of personal taste, but that seems to vary.
I will come up with a proposal and then we can discuss further based on that.
Thanks for this library, first of all! I am using it to flip the light switch in my workshop after receiving a command over MQTT. Works nicely!
I was looking into testing my code a bit more and wanted to fake (mock) the real servos in my test code. I found ArdiunoFake, which is based on FakeIt. Both are focused on providing mocks of interfaces, which is hard (impossible?) to do with concrete classes like Servo.
Looking at the code, it seems quite possible to rename the current
Servo
class to e.g.ServoESP32
and then extract a newServo
interface from it. Doing this would make mocking and testing the code usingServo
possible or at least much easier.The downside would that it breaks backward compatibility. If that is an issue, keeping
Servo
and extractingIServo
would be a possibility (not preferred by me, at least).Before investing time into that, I wanted to check if there is interest in a contribution like this, or if there are alternative suggestions how to unit-test code that is using this library without having to attach an actual servo during testing.