<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 31, 2013 at 8:29 AM, Jonathan Druart <span dir="ltr"><<a href="mailto:jonathan.druart@biblibre.com" target="_blank">jonathan.druart@biblibre.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So there are 3 kinds of failure causes:<br>
1/ C4::XISBN::get_xisbns fails because the connection to an external<br>
data source cannot be established.<br>
2/ data is not created by the unit tests and does not exist in the sample files.<br>
3/ a test "normally" fails<br>
<br>
For 1, is it consistent to mock the connection ?<br></blockquote><div><br></div><div>Mocking the connection is an option, but IMO it's better to attempt a real connection, and have the test skip if the connection cannot be established.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For 2, I think it could be resolved using the idea from bug 10337:<br>
reset the DB data before launching tests.<br></blockquote><div><br></div><div>I think some tweaking is needed for that proposal.  It's one thing to have Jenkins reset its database(s) before running a build, but I feel strongly that we should encourage ordinary developers to feel free to run prove -v t/db_dependent/whatever.t at any time against their main development database.  We're pretty close to that being safe now, and once all of the DB-dependent tests run in a transaction, it will be safe enough for a developer to run any and all of the tests at will.</div>
<div><br></div><div>That's not to say that there shouldn't be scripts available for a developer to set up a separate testing database and easily reset it at will, too, but I don't think they belong as a mandatory test under t/db_dependent.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It would be great to receive mails from Jenkins saying the master is<br>
unstable only if is a code issue (and not a connection issue or a lack<br>
of data).<br></blockquote><div><br></div><div>Well, there is always going to be the possibility of a problem with the test system, so it's never going to be perfect.  For example, if nothing else there will always be the possibility that the </div>
<div><br></div><div>I think it might be better if we give folks the option to subscribe to emails from Jenkins, not get them automatically if one of their patches just happens to be in a set that triggered a test failure.</div>
<div><br></div><div>RMs and RMaints need to care about Jenkins test results.  QA team members should also care.  So should ordinary developers, but that doesn't necessarily mean that they have to unconditionally get the nags from Jenkins. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Moreover, we have some unit test files which are never launched. So if<br>
a regression is introduced on routines covered by these unit tests, we<br>
are not alerted.<br>
The prove command should be launched with the recursive flag.<br></blockquote><div><br></div><div>That would be a goal, but because of dependencies, particularly the Solr stuff, we're not yet at the point where prove -r t/, when run on a Jenkins build server, will not result in test failures.</div>
<div><br></div><div>If there are specific tests that you've noticed that aren't being run, please enumerate them and I can adjust the Jenkins config.</div><div><br>Regards,</div><div><br></div><div>Galen</div></div>
-- <br><div dir="ltr"><div>Galen Charlton</div><div>Manager of Implementation</div><div>Equinox Software, Inc. / The Open Source Experts</div><div>email:  <a href="mailto:gmc@esilibrary.com" target="_blank">gmc@esilibrary.com</a></div>
<div>direct: +1 770-709-5581</div><div>cell:   +1 404-984-4366</div><div>skype:  gmcharlt</div><div>web:    <a href="http://www.esilibrary.com/" target="_blank">http://www.esilibrary.com/</a></div><div>Supporting Koha and Evergreen: <a href="http://koha-community.org" target="_blank">http://koha-community.org</a> & <a href="http://evergreen-ils.org" target="_blank">http://evergreen-ils.org</a></div>
</div>
</div></div>