<div dir="ltr"><div>There was a lot of +1 support on the PR. The basic Pulp3 unit test policy can be seen here: <a href="https://docs.pulpproject.org/en/3.0/nightly/contributing/unit_tests.html">https://docs.pulpproject.org/en/3.0/nightly/contributing/unit_tests.html</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 5, 2018 at 1:06 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>This is a wrap-up update with the last next steps (for now) on the Pulp3 unit test discussion.<br><br></div><div>1. Here is a docs PR adopting simple but specific policy language recommending unit tests for Pulp3: <a href="https://github.com/pulp/pulp/pull/3411" target="_blank">https://github.com/pulp/pulp/<wbr>pull/3411</a><br></div><div>2. We need to move our existing unit tests into their "forever home" so @daviddavis and I groomed this issue and put it on the sprint:  <a href="https://pulp.plan.io/issues/3553" target="_blank">https://pulp.plan.io/issues/<wbr>3553</a><br></div><div><br>For any areas of Pulp3 untested code that you want to add unit tests for please file a Task in Redmine for that. A few of those have been filed AIUI.<br></div><div><br></div><div>If there are any issues with these changes please bring them up. Any aspect of them can be rethought. David and I have tried to facilitate what we've heard from the group.<br><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 5:13 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I want to summarize what I've heard to facilitate some next steps and further discussion.<br><br>There seems to be broad support and no -1 votes to the idea of a soft check that tracks unit test coverage, so we wanted to get that out of the way. Daviddavis enabled unit test coverage reporting for all Pulp3 PRs (<a href="https://github.com/pulp/pulp/pull/3397" target="_blank">https://github.com/pulp/pulp/<wbr>pull/3397</a>) and it will report on all PRs now. Currently, it shows 54.98% for pulpcore. That number is surprisingly high but not awesome. When looking at the report, it is mainly all import statements and function definitions since we have few/zero unit tests but also not much code.<br><br></div><div>Based on feedback it sounds like leaving it at a soft check and highly encouraging unit tests with each PR is something we could all agree on. I want us to get to specific language that we can add into the Pulp3 docs as a new section called "Unit Tests" here: <a href="https://docs.pulpproject.org/en/3.0/nightly/contributing/index.html" target="_blank">https://docs.pulpproject.org/e<wbr>n/3.0/nightly/contributing/ind<wbr>ex.html</a> Here is a starting point, please send suggestions:  "All new code is highly encouraged to have basic unit tests that demonstrate its functionality. A Pull Request that has failing unit tests cannot be merged."<br><br><br></div><div>Also from the convo on-list and on-irc, here are some questions I would like help answering:<br><br></div><div>* What areas in the existing codebase would really benefit from unit testing? I think we need a classpath list of modules and classes. I made an etherpad here: <a href="https://etherpad.net/p/Pulp_Unit_Test_Candidates" target="_blank">https://etherpad.net/p/Pulp_Un<wbr>it_Test_Candidates</a><br><br></div><div>* What are the existing unit tests and where do they live?<br><br>* What docs need to be added to make contributing unit tests reasonable?<br><br><br></div><div>Thanks for all the discussion!<span class="m_-7562143959397482369HOEnZb"><font color="#888888"><br></font></span></div><span class="m_-7562143959397482369HOEnZb"><font color="#888888"><div>-Brian<br></div><div><br></div></font></span></div><div class="m_-7562143959397482369HOEnZb"><div class="m_-7562143959397482369h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 4:01 PM, Jeremy Audet <span dir="ltr"><<a href="mailto:jaudet@redhat.com" target="_blank">jaudet@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> I'm also generally -1 against trying to pick a number (100%, 80%, 60%) up-front.  We should unit test what makes sense to unit test, push that number as high as reasonable, and otherwise focus on pulp-smash, which I think has historically been more useful.<br>
<br>
</span>QE is flattered by the focus on Pulp Smash. We're happy that the smoke<br>
tests are being executed as a pull request check.<br>
<br>
However, it's important to remember that unit tests are far faster<br>
than integration tests, typically by several orders of magnitude. In<br>
addition, Pulp Smash's smoke tests are intentionally limited. They're<br>
designed to execute quickly and to detect catastrophic regressions.<br>
They're not intended to be comprehensive. In fact, some of the<br>
already-written test cases may be stripped of their "smoke test"<br>
status for the sake of speed. Psychology is important here: it's bad<br>
if a developer locally fires off smoke tests, gets bored, and opens up<br>
a new web browser tab.<br>
<br>
Please keep this limitation in mind when deciding on policies<br>
regarding smoke tests.<br>
<div class="m_-7562143959397482369m_5806814774588513631HOEnZb"><div class="m_-7562143959397482369m_5806814774588513631h5"><br>
______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>