Skip to content
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

adding test code #869

Open
2bndy5 opened this issue Sep 5, 2022 · 0 comments
Open

adding test code #869

2bndy5 opened this issue Sep 5, 2022 · 0 comments

Comments

@2bndy5
Copy link
Member

2bndy5 commented Sep 5, 2022

A while ago I removed the old tests from maniacbug days because they relied on older Arduino compilation convention and necessary hardware (RX & TX nodes driven by AVR-based MCUs from a Linux host). I think its time to tackle the creation of new tests.

  1. Software tests should ensure expected behavior in all methods & attributes. I intend to override SPI transactions to do this, so I can match SPI out/input with the expected behavior. If we use a test lib like catch2, we could optionally perform software tests with CMake. These may be be limited to Linux only because of the time-oriented libs that we use.
  2. Hardware tests should be similar to what maniacbug had done but modernized by using PlatformIO. Running hardware tests will be no more tedious to setup than any Arduino example (which only highlight radio features instead of lib features). If we utilize the platformio.ini configs properly, it should be simply a matter of specifying the right PIO env from PIO CLI.
    • It may be possible to use ArduinoCLI tool, but PIO seems easier out-of-the-box.

Additional context

It would be prudent to add tests that would ensure compatibility with other libs like ArduinoJSON, but that is a secondary goal for now.

Implementation details like how to override SPI transactions for software tests are TBD (what this thread is meant for). Initially, I thought about making read/write_registers(), ce(), and csn() protected when a RF24_TESTS macro is defined. But, it may be easier to use a utility/test driver instead (which would allow using cross-platform compatible time-oriented libs as well).

If done right, this could be extended to pyrf24 pkg. And yes, I am also considering the other RF24* libs, but that should be rather trivial after this is done with the RF24 core lib.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants