-
Notifications
You must be signed in to change notification settings - Fork 8.1k
tests: drivers: can: api: Add test teardown #98039
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
Conversation
Stop the CAN device in the test teardown to leave the CAN device in a neutral state. Signed-off-by: Sebastian Huber <[email protected]>
d509869 to
57a737b
Compare
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The description only says what you are changing, not why.
How come this is needed?
When you run multiple test suites (for example can_classic and can_timing) in a single application, the can_timing test suite could fail since the CAN device is started when the timings are set. |
How would you run these "in a single application"? These are two, distinct test suites, each an application on it's own. |
I don't use Zephyr directly. I use parts of Zephyr together with the RTEMS real-time operating system. The operating system and the Zephyr components are shipped as a static library. I would like to test the library in exactly one configuration. To reduce the test time, I would like to run multiple tests suites in one executable. The test suites support setup and teardown handlers, so from a testing point of view this should be fine. |
This is in noway supported by Zephyr, sorry. |
It works pretty well, however, the rejection of changes like this just makes it harder. What is the cost for the Zephyr project to properly teardown a test suite even if it is not strictly required in the current arrangement? The test support has all the means to do this and calling a single function which is already used by the test suite is a very small overhead. You already have to do the stop/start for some test cases. |
The cost is, that your use-case may break in another, unrelated way tomorrow. We have no means of verifying that this does not break (and it is not a supported use-case), so trying to maintain support for this will be chasing an undefined goal. We cannot spend the time of upstream developers, maintainers, collaborators, and reviewers on this. |



Stop the CAN device in the test teardown to leave the CAN device in a neutral state.