-
Notifications
You must be signed in to change notification settings - Fork 185
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
Add CI Testing Section #87
base: master
Are you sure you want to change the base?
Conversation
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.
See second comment: I think this needs a better understanding of audience and goal. I'm not sure what the reader walks away from this with or who its targeted at. It doesn't really explain how to write any given type of test or the tools around it. It also isn't detailed enough to act as a desk reference for codecov / gtesting / rules.
tutorials/docs/ci_testing.rst
Outdated
Benefits of Automated Testing | ||
============================= | ||
|
||
.. image:: images/CI_Testing/code_coverage_bump_40_80.png |
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.
What's the point this image is trying to convey?
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.
Basically "stonks" (the meme).
A growing coverage should motivate others to help raise the bar to 100 (or as you more realistically said: 90%).
And they should question themselves what it takes to create such a huge bump from 40 to ~75.
Also, they should see that it can be big jumps and also small jumps (new tests added) that also help improve.
So basically multiple things, that also motivated me to write something about it..
Disclaimer: I'm absolutely new to CI / testing. I just wrote down my understanding of things while I discovered them. So thanks for the input! I'll try to improve the points you mentioned and learn a few things more on the go.
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.
Lets not use this image, its deceptive, its a little more complex to describe why that jump happened, but its not as obvious as you think
tutorials/docs/ci_testing.rst
Outdated
Whenever a feature gets added or altered, it is best practice to confirm the intended outcome with automated test scripts. | ||
This document features an easy step by step guide how CI should be integrated alongside new PRs. | ||
|
||
Also, not only new code should have CI testing. To find nasty bugs and corner cases, it is Nav2's ultimate goal to have a test coverage of nearly 100% ! |
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.
.... don't make promises for me ;-)
Lets change that to 90%. That's my goal for every individual package.
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.
sure thing.. :-) done.
tutorials/docs/ci_testing.rst
Outdated
@@ -0,0 +1,224 @@ | |||
.. _ci_testing: |
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.
So the big things here are:
- Audience: who is this document for?
- Goals: What is this document trying to accomplish?
Its not clear to me what this is trying to do. I don't disagree having some content about testing in documentation, but I'm not sure what the aim or audience this document has.
"CI" seems odd here too. You mostly talk about testing, almost nothing about CI beyond the code coverage report.
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.
Audience:
Get new folks involved with testing. So programmers that already added some code and want to nicely finish their PR with tests but have no clue where to even start looking in a massive project like nav2.
Testing does not take ages to figure it out by themself, but it should be just something that gives you some good starting points and get to the point and continue programming
Goal:
Make clear to them that testing is not hard and can help you to get to know your code better
CI and testing where synonyms for me at the beginning of this document. Testing in CI is also just a little chapter of CI.
Probably should remove CI references in the file names..
But changed the setting now a bit. Let me hear what you think.
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.
So why is it called "CI testing" if its meant for new people learning about testing?
I'm not sure this really hits the target on helping people get into testing. There's not really a linear narrative explaining concepts, showing how to use tools, and helping write tests. There's no real mention or details on gtest and test-launch and the ament testing tools, which I'd think would be necessary for a "how do I setup tests" tutorial. There's not any code to be a "writing my first test" tutorial. There's not really a clear direction this content is going in - seems to me like a bunch of assembled facts but isn't guiding a reader towards understanding any particular aspect of testing.
tutorials/docs/ci_testing.rst
Outdated
1. Run Existing Tests | ||
--------------------- | ||
Nav2 specific tests can be found in each individual component under a dedicated test folder. | ||
One additional package, ``nav2_system_tests``, `exists <https://github.com/ros-planning/navigation2/tree/main/nav2_system_tests>`_ for testing components, sub-systems and full system tests. |
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.
", in addition to unit and integration tests in individual packages."
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.
done
tutorials/docs/ci_testing.rst
Outdated
To run existing tests of components or the whole system from within the ``nav2_system_tests`` package, you can use this procedure: | ||
|
||
- build nav2 with ``$ colcon build --symlink-install`` | ||
- navigate to the component you would like to test ``$ cd build/<package_name>`` |
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.
This isn't good. You can just do colcon test --packages-select <pkg-name>
to run the tests of an individual package. You should never need to go into build
.
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.
yes you can do that.
But it is a really really long command this way..:
colcon test --event-handlers console_direct+ --packages-select <pkg-name> --ctest-args -R <regex>
I especially want to see the output via the event-handlers as I need to see what is happening with my new test. The new test mostly is not right the first time. (during normal test times, this should show nothing as it is currently)
Probably still better to use colcon than go to the build folder.
Done.
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.
You're talking about in this section about running "existing tests of components", so you should target that audience. Not the "run a single new test" audience, these are different things.
tutorials/docs/ci_testing.rst
Outdated
|
||
.. code-block:: text | ||
|
||
ament_add_gtest(test_action_spin_action test_spin_action.cpp) |
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.
Please explain these cmake macros and what each do
tutorials/docs/ci_testing.rst
Outdated
|
||
.. code-block:: text | ||
|
||
ament_add_test(test_bt_navigator_with_groot_monitoring |
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.
This isn't just for python, this is for running any launch-based test vs a raw gtest
test. So all these examples are used to run launch files which have test nodes that are launched as well as python. But they dont need to be python.
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.
Changed it.
I thought that launch scripts in ros2 must always be python
tutorials/docs/ci_testing.rst
Outdated
Is there room to improve the test coverage near your code? Ain't you just the right expert about this code section? | ||
Think about adding tests that exceed your own focus and help improve nav2/ros2 reach a higher overall code coverage and ultimately also quality. | ||
|
||
The report above is an automated post by codecov.io-bot on github that posts results of CI automatically for every new PR. |
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.
I'd also recommend seeing the report and look at the files you modified to see the specific lines that were / weren't covered (or see the new package total %). That can help you see where you need to add more tests for or if you hit your test coverage goal (sometimes there's noise in just that high level % from other packages moving around a little).
tutorials/docs/ci_testing.rst
Outdated
|
||
Rewriting Parameter Values from YAML Files in Launch scripts | ||
============================================================ | ||
In most occasions some small new features are added and made available through a few new parameters. As the standard nav2 user should not be overloaded with features it makes sense to disable most of the additional or drop-in features in the default ``params.yaml`` file. |
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 explanation here doesn't 100% explain why this is in this document.
tutorials/docs/ci_testing.rst
Outdated
.. note:: | ||
When testing with ``pytest`` - typically for ros2 launch files - and building your package with ``$ colcon build --symlink-install``, you can even change your test scripts without rebuilding the whole package! | ||
|
||
3. Writing Your Own Test |
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.
Explaining gtest would be good. Or links to launch test uses
also included ref to two similar tutorials by autoware that I came aware of shortly after finishing after what I changed now.. Maybe this covers a few more points that would be interesting as well..?
there are 4 uncommented requests from you that I will come back shortly. |
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.
I think you pushed your groot stuff to your CI testing PR branch, then deleted your CI testing work.
====== ======= ======= ======== | ||
Type Default Unit Optional | ||
------ ------- ------- -------- | ||
int 1666 Port yes |
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.
Remove these optional fields, any parameter with a default is technically optional. As well with unit, please stick with the format unless you'd like to update all of the parameters in all of the guides to this new format 😉
@@ -0,0 +1,88 @@ | |||
.. _groot_introduction: |
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.
Groot tutorial and deleted the CI testing tutorial? I'm confused, this is the CI testing section PR.
Please revert all groot stuff from this PR and open a new PR with groot docs. I won't review this PR with 2 different things in it that aren't related. |
Hey,
I just explored CI testing for myself and had the feeling of writing about what the spirit of CI testing is and what entry points for CI beginners might be interesting.
Also included is my example of a working partial script of RewrittenYaml.
Hope this fits into the documentation?
Cheers