Replies: 3 comments 6 replies
-
|
Please use the GitHub Discussions for general questions as mentioned in the README.md. |
Beta Was this translation helpful? Give feedback.
-
|
first of all, thank you for this great lib! so i'd like to test some code that calls analogRead. i'd like to test what happens when analogRead is a certain value, but i'm having a loss knowing how to go about doing that. |
Beta Was this translation helpful? Give feedback.
-
|
There are at least 3-4 different ways of doing this, I was hoping to get a sense of the application that you are trying to test, and a sense of your level of expertise of C++. First, it's important to remember that AUnit and the tests were designed to run on the microcontroller itself. The Arduino API has zero support for testing of any kind, so everything we do is to work around this fundamental limitation of the API. Let's take a look at In order to test your code that calls these functions, you must manually instrument your code, and manually insert a layer of indirection between your code and the Use a custom version of analogRead() and digitalRead()If your application is written using traditional C procedural style using mostly functions, then instead of using extern bool isTestingMode;
extern int analogReadValue;
extern int digitalReadValue;
int injectableAnalogRead(uint8_t pin) {
if (isTestingMode) {
return analogReadValue;
} else {
return analogRead(pin);
}
}
int injectableDigitalRead(int8_t pin) {
if (isTestingMode) {
return digitalReadValue;
} else {
return digitalRead(pin);
}
}Then in your app, you call test(myTest) {
analogReadValue = 23;
// your code
assertEqual(..., ...);
..
}
void setup() {
isTestingMode = true;
...
}
void loop() {
aunit::TestRunner::run();
}The disadvantage of this method is that you always pay for the overhead of the Use C++ Runtime PolymorphismIf your application is written in OOP style using classes and objects, you could insert a layer of indirection by using a virtual function: class Reader {
public:
virtual int analogRead(uint8 pin) const = 0;
virtual int digitalRead(uint8_8 pin) const = 0;
[...]
};
class HardwareReader : public Reader {
public:
virtual int analogRead(uint8 pin) const override { return ::analogRead(pin); }
virtual int digitalRead(uint8_8 pin) const override { return ::digitalRead(pin); }
[...]
};
class TestableReader : public Reader {
public:
int analogRead(uint8 pin) const override { return mAnalogReadValue; }
int digitalRead(uint8_8 pin) const override { return mDigitalReadValue; }
void setAnalogReadValue(int value) { mAnalogReadValue = value; }
void setDigitalReadValue(int value) { mDigitalReadValue = value; }
[...]
private:
int mAnalogReadValue;
int mDigitalReadValue;
};Then you write the cod that you want to test using a pointer or reference to the interface class MyApp {
public:
MyApp(const Reader* reader) :
mReader(reader)
{}
void doSomething() {
int value = mReader->analogRead(pin);
[...]
}
[...]
private:
const Reader* mReader;
};In your real code, you inject the actual HardwareReader reader;
MyApp myApp(&reader);But in your AUnit test code, you inject the TestableReader reader;
MyApp myApp(&reader);The disadvantage of this is that dynamic dispatch (i.e. calling functions with the Using C++ Templates for Compile-time PolymorphismThis requires a fairly advanced level of understanding of the C++ language and its template programming techniques. I've been playing around with this the last year or so, and I've had some good success with it, but I have to be honest, this isn't for beginners. The core idea is similar to the previous runtime polymorphism technique, but you use C++ template to achieve compile-time polymorphism. The advantage is that the compiler optimizes out almost all of the layer of indirection that you add to get testability, and you save in flash memory and performance. The drawback is that the code becomes very complicated. Here, we have 2 different Readers, but we don't use C++ polymorphic inheritance, there is no class HardwareReader {
public:
int analogRead(uint8_t pin) { return ::analogRead(pin); }
int digitalRead(uint8t_t pin) { return ::digitalRead(pin); }
};
class TestableReader {
public:
int analogRead(uint8_t pin) { return mAnalogReadValue; }
int digitalRead(uint8t_t pin) { return ::digitalRead(pin); }
int mAnalogReadValue;
int mDigitalReadValue;
};Now we write the application, or the code that you want to test as a template class, making the injectable Reader class into a template parameter template <typename R>
class MyApp {
public:
MyApp(const R& reader) : // pass by const-reference
mReader(reader)
{}
void doSomething() {
int value = mReader.analogRead(pin);
[...]
}
[...]
private:
R mReader; // hold by-value
};(Edit: Changed constructor to pass In your real code, you inject the HardwareReader reader;
MyApp<HardwareReader> myapp(reader);But in your unit test, you inject the TestableReader reader;
MyApp<TestableReader> myapp(reader);As I mention, the biggest advantage of this is that you avoid all of the runtime overhead of dynamic polymorphism. The compiler is often able to inline most of the calls through the I can think of at least one other way of doing things like this, but I hope these 3 techniques points you in the right direction. Remember, the purpose of the AUnit library to give you a framework for making assertions, through the various P.S. The code above was written off the top of my head, without any checking of syntax, so there are probably tons of typos and syntax errors. But I hope you get the idea. |
Beta Was this translation helpful? Give feedback.
-
|
wow, @bxparks i'm really grateful for you detailed and robust reply! after considering those proposals, i actually decided on something else: Instead of calling |
Beta Was this translation helpful? Give feedback.
-
|
Yup, that works if your state machine is relatively simple, and your event production and event consumption can be decoupled cleanly. But in many cases, it can be difficult to do that decoupling. For example, let's say your |
Beta Was this translation helpful? Give feedback.
-
|
yea. i need to dive into C++. i feel pretty comfortable with C, java, and go, but C++ is completely different... |
Beta Was this translation helpful? Give feedback.
-
|
Learning some amount of C++ for Arduino stuff will be very useful. Personally though, the cognitive complexity of the language is starting to wear me down, even after (maybe especially after?) using it on and off for 30 years. C does not give me enough abstractions and expressive power, but C++ is out of control. So I'm looking for alternatives. I looked at MicroPython. But Python is actually a really complex language underneath its friendly veneer. The runtime overhead on a microcontroller seems too much for anything more than prototypes, and MicroPython requires special language extensions to make the resource consumption tolerable on small microcontrollers. The code deployment process also seems inefficient: I don't want to load the actual Python source code to the microcontroller, I want to compile down to bytecode on the host machine, catch all the compile-time errors, then load just the bytecode. This doesn't seem to be supported, at least I couldn't find it. And the ecosystem is fractured into CircuitPython and MicroPython. TinyGo is next on my list to evaluate, and seems promising. Maybe I'll look at Nim, which supposed to transpile to C, but I don't know well it supports the Arduino or other microcontroller environments. And maybe Zig, although they say that a stable v1.0 is several years away. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe rust will fullfill your needs :-D I'm working with C++ for 30 years also. I still like this langage, but yes, the complexity of this langage is a brake ! I'll will have a look to Rust this year. |
Beta Was this translation helpful? Give feedback.
-
|
See bxparks/EpoxyDuino#76 for a similar discussion about mocking/injecting Arduino functions. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Beta Was this translation helpful? Give feedback.
All reactions