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

Move hysteresis test to gtest #12049

Merged
merged 3 commits into from
May 27, 2019
Merged

Move hysteresis test to gtest #12049

merged 3 commits into from
May 27, 2019

Conversation

julianoes
Copy link
Contributor

I did the move of the hysteresis class as I envision it. It's now a self-contained simple class without dependencies or side effects and the unit tests run immediately and won't ever by flaky because of stalled CI hosts.

I agree that we still want to run unit tests like these on real hardware, I'm therefore planning to run the gtest tests on a Pixhawk and if that's impossible we need to find some test framework that makes it possible.

I'm not sure yet if every module should come in this form, so without many dependencies, or if we need higher level tests for some "modules".

@julianoes julianoes requested review from dagar and MaEtUgR May 20, 2019 14:15
@dagar
Copy link
Member

dagar commented May 20, 2019

Playing devils advocate for a minute, don't you think this makes hysteresis slightly easier to misuse?

@julianoes
Copy link
Contributor Author

Playing devils advocate for a minute, don't you think this makes hysteresis slightly easier to misuse?

Yes, I agree, the API is suboptimal.

@julianoes
Copy link
Contributor Author

@dagar an alternative would be to set a fake clock and inject it into the constructor of the Hysteresis object, or some global set up of the fake clock.

@dagar
Copy link
Member

dagar commented May 20, 2019

I don't think shifting some of the complexity to the caller in order to enable faster more convenient unit tests is ultimately going to put us in a better place. Maybe this is a trivial example to get hung up on or maybe that makes it easier to discuss.

As much as possible I'd rather we encapsulate these things to make them easy to use, hard to misuse.

What if we did something within the framework of lockstep SITL (fake clock), but drove it internally as fast as possible (without the simulator)?

@julianoes
Copy link
Contributor Author

What if we did something within the framework of lockstep SITL (fake clock), but drove it internally as fast as possible (without the simulator)?

Yes, I'll think something like that could work. On the other hand many classes - in my opinion - should have less dependencies and side effects, and time is one of those things.

MaEtUgR
MaEtUgR previously approved these changes May 23, 2019
Copy link
Member

@MaEtUgR MaEtUgR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I clearly favour this way since:

  • The unit test makes sure the logic does what it should without hanging on system calls
  • We are not blocked from saving hrt_absolute_time() calls when we have multiple hysteresis that are checked with the same pace. E.g. it's possible to implemet an efficient hysteresis vector.
  • It's more modular and hence portable


px4_add_library(hysteresis hysteresis.cpp)

px4_add_gtest(SRC hysteresis_test.cpp LINKLIBS hysteresis)
Copy link
Member

@MaEtUgR MaEtUgR May 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you name the file HysteresisTest.cpp after the convention?
Then the script would automatically handle consistent output: https://github.com/PX4/Firmware/blob/ea48cd4970977f4d189c1a9ba82483ac03852299/cmake/gtest/px4_add_gtest.cmake#L55

This moves the hysteresis test out of the systemlib and makes it its own
small library. Since it still depends on hrt_absolute_time this does not
link yet. My attempt to get all link dependencies together failed.
@MaEtUgR
Copy link
Member

MaEtUgR commented May 23, 2019

I changed the filename according to my comment and am rebasing on master since I introduced the conflicts.

@MaEtUgR MaEtUgR force-pushed the pr-move-hysteresis-test branch from 7765917 to 03e7fb7 Compare May 23, 2019 13:30
Copy link
Member

@MaEtUgR MaEtUgR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, hysteresis still depends on the abstime type but we can remove that in another step.
I SITL checked that the spoolup time still does what it should.

@julianoes julianoes merged commit 8a84472 into master May 27, 2019
@julianoes julianoes deleted the pr-move-hysteresis-test branch May 27, 2019 07:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants