<div dir="ltr">On 7 March 2016 at 23:45, Eric Harney <span dir="ltr"><<a href="mailto:eharney@redhat.com" target="_blank">eharney@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
</span>I'm not really sure that writing a "hacking" check for this is a<br>
worthwhile investment.  (It's not a hacking check really, but something<br>
more like what you're describing, but that's beside the point.)<br>
<br>
We should just be looking for large, complex unit tests in review, and<br>
the ones that we already have should be moving towards the functional<br>
test area anyway.<br>
<br>
So what would the objective here be exactly?<br><br></blockquote><div><br></div><div>Complexity can be tricky to spot by hand, and expecting reviewers to get it right all of the time is not a reasonable expectation.<br><br></div><div>My ideal would be something that processes the commit and the jenkins logs, extracts the timing info of any new tests, and if they are outside some (fairly tight) window, then posts a comment to the review indicating that these tests should get closer scrutiny. This does not remove reviewer judgement from the equation, just provides a helpful prod that there's something to be considered. <br></div><div> </div></div><div class="gmail_signature"><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div></div>