Seeking Example of mocking input for button long press.

[EricLauber]

I've written a function for detecting user input from a physical button. It uses a while loop that begins with a digitalRead and calls millis() to determine when the button is pressed and let go. The length of time leads to whether this was a short press or a long press.

I've seen AUnit examples that mock different values that digitalRead will return for a particular pin, but I'm wondering about how to tie this to time. Something like "at this time, return this mock value, and then at this later time, change the value."

If it's not possible to accomplish this mocking with the digitalRead, I can always wrap my button class or inherit it from an abstract class (an interface) and build a mock class to use in the tests - but if I can mock the time and change in values from the read, that helps prove more of my code is sound.

Does anyone have examples I can reference?

[bxparks]

I think you might be conflating 2 things which are independent of each other: One, the mocking and testing of digitalRead(), and Two, the mocking and testing of the clock implemented by the millis() or micros() functions in Arduino API.

For digitalRead(), the Arduino API provides no support for mocking, but as you probably discovered, the EpoxyDuino API provides the digitalReadValue() function to inject mock values.

For millis() or micros(), the Arduino API again provides no support for mocking, and unfortunately, neither does EpoxyDuino. (That's because EpoxyDuino was never intended to be mocking framework, it was intended to be an emulation of the Arduino API on Unix machines.) So, you have to inject a fake clock on your own. There are probably several ways to do this, I'll write down a few options:

1. Inject a Template ClockInterface (difficult)

This requires you to write your code as C++ templates, and inject a TestableClockInterface class, instead of the real ClockInterface class. I do this in several of my libraries, because it produces the most efficient code. But this requires some level of expertise with template programming, which you may not want to use. See

• https://github.com/bxparks/AceTimeClock/tree/develop/tests/SystemClockTest
• https://github.com/bxparks/AceRoutine/tree/develop/tests/AceRoutineTest

2. Override virtual millis() using a subclass (easier)

This assumes that you are using classes and OOP techniques. You create a virtual method named millis() in the class that you want to test. In the production code, the millis() is wired to the global ::millis(). In the unit test, you create a subclass with an overridden millis() method whose return value can be controlled by a setMillis() method (or something like that).

The advantage of this technique is that it's usually easier to understand for most people. The disadvantage is that the runtime polymorphism of the millis() method incurs a small CPU time overhead. Most of the time, this overhead will not matter, but sometimes it can be important.

See

• https://github.com/bxparks/AceButton/tree/develop/tests/AceButtonTest

3. Use a custom millis() function. (simple)

Instead of using the Arduino millis() or micros(), use your own function as a layer of indirection, e.g. myCustomMillis() and myCustomMicros(). Then in the implementation of those functions, check a global flag to determine if it is in testing mode or production mode. If in testing mode, make those functions return an injected mock value instead of the actual ::millis() or ::micros().

The advantage of this is that the code is quite simple and easy to understand. The disadvange is that you have to have modify the calling code to use your custom clock functions, instead of the Arduino builtin clock functions. The other disadvantage is that there is a runtime overhead from the code checks whether the code running in test mode or production mode, similar to the overhead of the virtual function millis() in Option (2) above.

4. Use CPP macros (untested)

It might be possible to use the C/C++ preprocessor to link in a different implementation of millis() and micros(). For example, something like:

unsigned long myCustomMillis() {
#if TESTING_MODE
    ...
#else
   ...
#endif
}

The problem with this technique is that it requires the ability to define the TESTING_MODE macro selectively (depending on testing or production). Arduino has consistently declined to provide this feature, but EpoxyDuino provides this by default because it uses the usual Unix tools: Makefile and g++ -D flag. But I've never actually used this technique myself, so it may have some unexpected warts.

Hope this gives you enough to point you in the right direction.

[EricLauber]

Thanks for the feedback. I might have mixed up what AUnit helps provide and what EpoxyDuino is able to accomplish.

Your 2 and 4 suggestions stick out the most to me personally. I'd have to test it to be sure but I suspect any CPU time overhead that occurs will not impact the test - it may have a millisecond impact, but I'm seeking to define a long press on the order of several seconds.

Let me see if I understand 2 correctly. I have a class for my Button and it has a function for getting the input. I would add a virtual function for millis() and when compiling prod code, the global ::millis() should override this, but in my test sketch I can also override it and define test behavior. Is that correct?

If so, maybe it makes sense to also combine it with suggestion 4 and define the presence of the virtual function to a macro? If that worked then in prod it would also eliminate the runtime polymorphism. Something like

#if TESTING_MODE
    public:
        virtual int millis() { }
#else
   // nothing!
#endif

My syntax may not be correct but I think that's the general idea.

I'm still leaning on also having my Button handling class inherit from an abstract class. This would enable me to create an entire mock alternative. I think the possible benefit here is I can unit-test any other components that would depend on this input (using the mock Button), and then potentially integration-test the Button class getting data from mock hardware.

[bxparks]

You have Option (2) mostly right. The easiest is to implement the prod code by default, and then override in the prod implementation in the test subclass:

class Parent {
  protected:
    virtual unsigned long millis() const { return ::millis(); }
  ...
};

class Child : public Parent {
  protected:
    unsigned long millis() const override { return mMillis; }
  public:
    void setMillis(unsigned long ms) { mMillis = ms; }
  private:
    unsigned long mMillis;
};

In testing mode, you would use Child class. So you are not directly testing Parent, but are relying on inheritance for the Child class to behave almost the same as Parent.

Yes you can combine (2) and (4), but if you do that, you probably don't need to make the millis() method virtual because you won't have a subclass. I have avoided option (4) because it is aesthetically ugly, and I always worry whether I can keep the environments correctly partitioned and organized, but it may be the easiest solution.

The CPU overhead of a virtual function is on the order of a few microseconds (Edit: or less), so in most cases, it should not make a difference. It's a good technique to have in your toolbox. On 8-bit AVR all processors, the virtual functions add additional memory overhead. In my experience, the memory overhead was more important than the CPU overhead, especially on resource-limited AVR processors. On most 32-bit processors, the memory overhead is so small, it's not worth even thinking about.

Whether to fully abstract your main Button class or not will depend on your use-case and context. Being able to fully test your class is good... but on microcontroller environments with poor support for mocking and testing, the overhead may not be worth it. You may find yourself going part way, and deciding that the chasing after the long-tail of testability and validation is not worth the squeeze.

[EricLauber]

This is more of a fun challenge for me so I'm good with trying both.

I created an IButton abstract class (interface) for myself and have set up the inheritance so that I can unit test other components with some mock implementations and inject those dependencies in. Great.

I'm starting down this path, where the Button class has a virtual method for millis() and a child class inherits this and overrides. It's almost exactly how you've gotten written above.

My parent class Button has a function that runs a loop to get input and measure the time from when the button is pressed until it is let go. We can now configure the millis() it reads to give the impression that time has passed. Is there a way with AUnit or EpoxyDuino to now change that value while the loop is running?

Something like....

ChildClassButton button = ChildClassButton(PIN);
// This function runs a while loop that continues until a short press or long press occurs
button.UpdateInputStatus();

Meanwhile...

// somehow in the midst of the loop, simulate the hardware changing state
digitalReadValue(PIN, 1);
button.setCurrentMillis(NEW_VALUE);

Alternatively, I wonder if I need to fire an event each time the loop completes so I can hook into that and inject new values in.

[bxparks]

You should refactor your loop so that you have access to each iteration, which then allows you to advance the fake clock manually. I suppose it is possible to inject an event listener into your loop, but I think that's a more complicated solution than opening up access into your loop iteration. An even more advance solution would be to use another thread to advance your fake clock. But I think that would be getting into silliness territory, because it would be far more error-prone and more difficult to debug. I think it's always worth going with the simpler solution whenever possible.

[EricLauber]

I hadn't thought of that with the loop. I could put the loop in function A, and the rest of the functionality in function B that I can call from the test sketch and from the loop. That sounds super reasonable.

[EricLauber]

I ended up implementing the suggestions and they are working for me. In my main Button class the call to get Button input runs a loop that calls upon a ReadButtonData() function each iteration. My fake Button class can set millisecond values as described above and then manually call ReadButtonData(). Since the fake Button inherits the original Button class it also works well with dependency injection and facilitates running tests well.

[bxparks]

(Reopening. I prefer to keep Discussions open so that other people can search for them easier. Issues are closed when they are fixed.)