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