Hello all,<br><br><div class="gmail_quote">2011/9/20 Caolán McNamara <span dir="ltr">&lt;<a href="mailto:caolanm@redhat.com">caolanm@redhat.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, 2011-09-19 at 21:18 +0200, Bjoern Michaelsen wrote:<br>
&gt; I am proposing introducing a new target in the build system called<br>
&gt; &quot;slowunitcheck&quot;. Those are tests that are technically unittests (need<br>
&gt; no full install), but considered to slow/longrunning to be run on every<br>
&gt; build. Instead those are run along the subsequenttests when running<br>
&gt; &quot;make check&quot; (or alone by running &quot;make slowunitcheck&quot;).<br>
&gt;<br>
&gt; Opinions?<br>
<br>
</div>If the goal is to support e.g. calc guys rebuilding fast when hacking<br>
sc, the more natural approach to me would be an extra non-unit-test<br>
module-level target, e.g. cd sc; make skipchecks or some such, an<br>
explicit opt-out-for-this-rebuild rather than out-in.<br>
<br>
I wonder exactly why/where the sc tests are slow, I mean linking the big<br>
test libs is definitely slow, is that the critical part of the<br>
slowdown ? Or is it running the tests ?<br>
<br>
I&#39;d kind of expect that linking the test would take the vast majority of<br>
time, if that&#39;s the case then for meaningful speedup the creation of the<br>
test would need to be skipped as well as the execution ?<br>
<br></blockquote></div><br>The
 sc unit tests are slow because we use the filter-tests as an way to 
test not only the import but also the first recalculation. We havenow already about 10 files that we import and check and I have some additional that are not yet finished. Then I&#39;m working at the moment on an similar approach to test vba code in sc. The problem with all these tests is that most of them are only relevant for certain cases and I think for example the bugFix files don&#39;t need to be executed by everyone.<br>
<br>I personally don&#39;t see the problem with calc devs here, but that as soon as they get slower and other people complain about them they might consider to skip all tests. So I prefer that everyone executes at least a basic set of tests during every build than someone skipping all tests because some special tests are too slow.<br>
<br>Regards,<br>Markus<br>