Esp WifiClient and WifiServer mock

[hsaturn]

EpoxyDuino and AUnit are together a great tool suite allowing to run tests fast and in a comfortable way on linux machine.

However, when used with AUnit, EpoxyDuino misses a mocks for WiFiClient and WiFiServer classes.

I've written such a mock here.
This mocks allows unit tests of my tinyMqtt library to run as an action with GitHub. Tests are now ran every time I pushes some code.

I'm continuing to develop this mock and have planned to include real packet transmission simulation with it. Anyway this won't be a real network stack because I won't spend time for that.

If you have the same problem, you can have a look on this AUnit.yml file. Keep in mind that EspMock is "quick and dirty".

Brian feel free to ask me full access to the repo of EspMock if ever you wanted to contribute or feel free to take the whole idea and code to do what you want with them.

[bxparks]

Thanks for letting me about https://github.com/hsaturn/EspMock. As I replied to your earlier email, you are correct that these ESP8266 and ESP32 mocks are not available in EpoxyDuino right now, for the simple reason that I have not personally needed them.

In addition to stubbed out libraries, I have thought that it would be interesting to create working implementations of these ESP libraries, on top of the Linux or MacOS network stack. That would allow certain Arduino programs to be developed fully within the EpoxyDuino framework.

It sounds like you plan to continue to add more features to your EspMock, as the need arises in your project. That's fine. What I will do is add a link to your EspMock from the EpoxyDuino README file, so that other people can find it.

To include these mocks within EpoxyDuino, I think I need to get a better understanding of how the various ESP libraries are organized and depend on each other. There are so many ESP header files (e.g. ESPWiFi.h, WiFiClient.h, WiFiClientSecure.h, ESP8266mDNS.h, ESP8266WebServer.h, DNSServer.h, WiFiUdp.h, and on and on), their organizational structure is confusing to me. Ideally, I would like the EpoxyDuino mock or emulated libraries to follow the same library structure as the real ESP8266 or ESP32 libraries. I don't think I want to place all ESP related mocks into one giant pile of stuff, unless someone thinks that it actually is good enough to do that.

[hsaturn]

*> I have thought that it would be interesting to create working implementations of these ESP libraries* I completely and fully agree... I've been able to use gdb and valgrind thanks to Epoxyduino ! And this is really a great thing ! *> To include these mocks within EpoxyDuino, I think I need to get a better understanding of how the various ESP libraries are organized and depend on each other.... * I do agree that obviously, EspMock is absolutely not ready to be included in EpoxyDuino. I do also need to have a better undertanding of ESP libs. I've invited you to https://github.com/hsaturn/EspMock. Yet, we can assume that EspMock is a sandbox allowing few things but not more. Francois Biot Le lun. 5 avr. 2021 à 04:37, Brian Park ***@***.***> a écrit :

…

Thanks for letting me about https://github.com/hsaturn/EspMock. As I replied to your earlier email, you are correct that these ESP8266 and ESP32 mocks are not available in EpoxyDuino right now, for the simple reason that I have not personally needed them. In addition to stubbed out libraries, I have thought that it would be interesting to create working implementations of these ESP libraries, on top of the Linux or MacOS network stack. That would allow certain Arduino programs to be developed fully within the EpoxyDuino framework. It sounds like you plan to continue to add more features to your EspMock, as the need arises in your project. That's fine. What I will do is add a link to your EspMock from the EpoxyDuino README file, so that other people can find it. To include these mocks within EpoxyDuino, I think I need to get a better understanding of how the various ESP libraries are organized and depend on each other. There are so many ESP header files (e.g. ESPWiFi.h, WiFiClient.h, WiFiClientSecure.h, ESP8266mDNS.h, ESP8266WebServer.h, DNSServer.h, WiFiUdp.h), their organizational structure is confusing to me. Ideally, I would like the EpoxyDuino mock or emulated libraries to follow the same library structure as the real ESP8266 or ESP32 libraries. I don't think I want to place all ESP related mocks into one giant pile of stuff, unless someone thinks that it actually is good enough to do that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRCSGYTQCULDVXMBMB7SRTTHEO7DANCNFSM42KXAMMA> .

[bxparks]

Thanks, I'll make some updates to EpoxyDuino/README.md and EspMock/README.md to let them know about each other.

I also want to mention that I think it's reasonable, maybe preferable, to have the "mock" ESP library be different than the "working" ESP library. The end-user can choose to use the specific library in the ARDUINO_LIBS variable of the Makefile. This allows them to use the mock library for CI, and the working library for actual application development. It also has the advantage of keeping the mock library simple and easier to maintain than the working library.

[hsaturn]

Great !

I've added unit tests to EspMock
Also, this mock is starting to be able to establish socket cnx

[bxparks]

1. Can you add a LICENSE file to EspMock? I release almost everything of mine under MIT License. Your project, your choice.

2. How do you want the collaborative development process to work? Do you want me to send you PRs through GitHub, or submit my changes directly into master? The latter means that you have to do git pull more frequently, to make sure that you get my changes. On the other hand, I don't have immediate plans of making lots of code changes right now, because I have so much other stuff to do... The only thing that I want to do right now is update the README.md files.

[bxparks]

@hsaturn

I've been thinking about this problem on and off for a few days, and I think I have found a solution. I have prepared 2 PRs:

• Allow selection of Arduino core files used by EpoxyDuino #29
• Use new EPOXY_CORE_PATH override to select ESP8266 core provided by this project hsaturn/EspMock#3 (depends on above)

To explain what these are doing, I have to provide a small amount of background. I came to the realization that there is not just one "Arduino API", but many different Arduino APIs, depending on the target hardware. Each architecture has implemented slightly different API. Some have modified the classes which were originally written for the AVR (e.g. most platforms have implemented a Serial.printf() method, which the AVR does not implement). Others have added new classes (e.g. the Esp class on the ESP8266 and maybe the ESP32, don't remember).

Originally, I did not intend EpoxyDuino to be able to mock or emulate every variation of the dozen (or more) different Arduino APIs that have been implemented for the various architectures. My intension was to implement just enough of the common functionality to be able to run most unit tests on a Linux or MacOS machine. The API implemented by EpoxyDuino is mostly derived from the AVR Core, but I think I added a few extensions for convenience.

Changes to EpoxyDuino

I realized that the "Arduino API" provided by the ESP8266 and ESP32 are sufficiently different from the AVR that it is no longer possible to use the default API provided by EpoxyDuino itself. We need to provide the ability to select a different Core under EpoxyDuino. To allow this, I created #29. I moved all of the Core Arduino API files from the top-level EpoxyDuino/ directory down to EpoxyDuino/cores/epoxy/. Then in EpoxyDuino.mk, I added 2 configuration variables:

• EPOXY_CORE
  • selects the version of the Core, the default value is epoxy and this will select EpoxyDuino/cores/epoxy/
  • if another set of Core files are created, then this can be set to an alternate set
• EPOXY_CORE_PATH
  • big hammer override
  • allows the end-user to provide a direct path to a custom set of Arduino Core files

Changes to EspMock

In hsaturn/EspMock#3, I moved around and modified various files, and copied a lot of files from EpoxyDuino into EspMock/cores/esp8266/ directory. These files form the ESP8266 version of the Arduino API. Then I changedEspMock/tests/network-tests/Makefile to add the EPOXY_CORE_PATH override:

APP_NAME := network-tests
ARDUINO_LIBS := AUnit TinyMqtt EspMock ESP8266WiFi
ARDUINO_LIB_DIRS := ../../libraries
EPOXY_CORE_PATH := ../../cores/esp8266
include ../../../EpoxyDuino/EpoxyDuino.mk

The EspMock.mk is no longer needed, because EPOXY_CORE_PATH tells EpoxyDuino to use the core files found in EspMock/cores/esp8266 (instead of using the default EpoxyDuino/cores/epoxy).

Why Duplicate So Many Files

The PR for hsaturn/EspMock#3 duplicates many files from EpoxyDuino. Why not create a common directory where files can be shared? Because I don't want to have tight coupling between the Arduino core files under EpoxyDuino and the Arduino core files under EspMock. If these files were shared between the two projects, every time something is changed in the shared files, we would have to make sure that nothing broke in the 2 dependent projects. That's too much work.

I also suspect that our priorities is a bit different. Currently, I don't have a strong need to compile ESP8266 applications or libraries under EpoxyDuino. But I suspect that I may need to implement my own version of EpoxyDuino/cores/esp8266 at some point. However, I suspect my version can be much lighter and not implement all the various functions provided by the actual ESP8266 core. However, it seems like you need a higher level of implementation of the various ESP8266 functionalities. With this separation, you can add those features to EspMock much faster if you didn't have to worry about breaking Epoxyduino.

Using the EPOXY_CORE_PATH override variable, the 2 esp8266 core files will not conflict with each other: the version at EpoxyDuino/cores/esp8266 will be independent from EspMock/cores/esp8266.

Let me know if you have any questions, @hsaturn !

[bxparks]

I'm planning to submit #29 this weekend since it makes EpoxyDuino more flexible, and it isolates its own set of "core" files from any extensions that may want to build on top of it.

[hsaturn]

Hello Brian Ok, I was waiting #29 for submitting your PR on EspMock. I won't make things longer even with files duplicates. After all EspMock is a quick & dirty fix and will probably not evolve a lot. Best regards Francois Biot Le ven. 23 avr. 2021 à 22:02, Brian Park ***@***.***> a écrit :

…

I'm planning to submit #29 <#29> this weekend since it makes EpoxyDuino more flexible, and it isolates its own set of "core" files from any extensions that may want to build on top of it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#27 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRCSG7YIOC25FSFYM4DJWTTKHG6VANCNFSM42KXAMMA> .