<div dir="ltr"><div><div><div>-1 for hard check, -1 for 100% coverage.<br><br></div>Unittests are good but integration tests are better.<br><br></div>I totally agree with what Austin said. We should add tests where it makes sense. +1 soft check.<br>I would not like finding myself banging my head [0] (just because of 100% coverage policy) against one line of code to cover which is not really realistic to happen, +1 complex to mock.<br><br></div>+1 to own policy of plugins.<br><div><br>[0] <a href="https://media.giphy.com/media/g8GfH3i5F0hby/giphy.gif">https://media.giphy.com/media/g8GfH3i5F0hby/giphy.gif</a><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div>
<br><div class="gmail_quote">On Fri, Mar 23, 2018 at 6:42 PM, Austin Macdonald <span dir="ltr"><<a href="mailto:austin@redhat.com" target="_blank">austin@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">-1 For a blocking check, -1 for attempting 100% coverage.<div><br></div><div>There is a *lot* of code in Pulp 3 that simply involves inheriting from parents classes and defining attributes. If we add a ViewSet for instance, there is nothing to test other than "asserting that we did what we did". I have written lots of tests like that. IMO, they add no value and are time consuming to write. Also, they are time consuming to maintain because every change must also change the unit tests. This type of test almost never catches a real problem.</div><div><br></div><div>A soft check would be a useful reminder to the contributor and the reviewer to add tests where they make sense. + 1 soft check</div><div><br></div><div>Plugins: Each plugin team should determine their own unit test policy. </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Mar 23, 2018 at 1:26 PM, David Davis <span dir="ltr"><<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>We haven't had a unit test policy in Pulp 3, and the community and core committers would all like one. The general desire we've heard so far is to change course and encourage developers to add unit tests to their changes to Pulp 3.<br></div><div><br></div><div>The policy we're suggesting is to add a coveralls[0] check for Pull Requests against the pulpcore 3.0-dev branch that shows the overall coverage percentage, e.g. 12.89%. This check would pass if and only if coverage increases or remains the same with the PR. We think this will eventually get us on the path to 100% unit test coverage.</div><div><br></div><div>We propose the coveralls check be a soft check that allow for merging if it fails. We would document the policy and try to adhere to it even though it wouldn't formally block merging. At a future point when pulp3 (maybe the GA?) we could make this a hard check.</div><div><br></div><div>Benefits:</div><div>- It's easy, simple, and automatic</div><div>- It's pretty objective and there's little room to argue with a number.</div><div>- Helps us raise our unit test coverage gradually over time</div><div><br></div><div>Downsides:</div><div>- Could discourage community contributions</div><div>- It can be a bit strict and unforgiving at times (especially if there's a hard check)</div><div>- It only provides a guarantee around quantity of unit testing and not quality</div><div><br></div><div><br></div><div><b>Q: What about the existing functionality? Do we need to write unit tests for it?</b></div><div><br></div><div>We're not sure about this. We'd like community feedback. Is anyone interested in writing backfill unit tests? If so, then maybe we should.</div><div><br></div><div><b>Q: Will this also affect Pulp 2?</b></div><div><br></div><div>We're not planning on it but if we like this enough, we can look at adding it to Pulp 2.</div><div><br></div><div><b>Q: Will this affect plugins?</b></div><div><br></div><div>We want to start out with just pulpcore now and see how we like it. Then we'll look at adding it to pulp_file. In the future, we can also look at ways to make it easy for plugins to set this up.</div><div><br></div><div><b>Q: Do I no longer need to write pulp-smash test plan issues in Github for Pulp 3 features?</b></div><div><br></div><div>No, you should still do that.</div><div><br></div><div>[0] <a href="https://coveralls.io/" target="_blank">https://coveralls.io/</a></div></div>
<br></div></div>______________________________<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>
<br></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>