<div dir="ltr"><div><div>IMO being a small team makes it an even better idea :) If you get used to it, I think you write solid new code faster _with_ tests than without.<br><br></div>I disagree we don't have a regression problem. Just think of the settings stuff that has been broken for months. Also we are scared to refactor stuff because it might cause bugs. My feeling is that we don't find many regressions just because we don't do enough human testing.<br>
<br></div><div>I admit the small team argument might be valid against doing 1. Writing tests for existing code helps with regression but it is time consuming. And given the general quality of the code base slowing down bug fixes might not be a good idea. I really don't have a strong feeling about this tough, I guess we have maintainers to take this kind of decisions :P<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 May 2013 15:36, Gonzalo Odiard <span dir="ltr"><<a href="mailto:gonzalo@laptop.org" target="_blank">gonzalo@laptop.org</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">May be I am old fashion, but requesting mandatory automated tests for all the changes is not a good idea.<div>
We are a small team. And we don't have a problem of regressions.</div><div>May be, with the new web api, with the many changes we will have in the next months,</div>
<div>is a good idea. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Gonzalo</div></font></span></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Fri, May 17, 2013 at 10:23 AM, Daniel Narvaez <span dir="ltr"><<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.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>Oh sorry, I suppose I should have made that clear :) I'm talking about automated tests, we have a few examples of them in the tree<br>
<br><a href="https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests" target="_blank">https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests</a><br>
<a href="https://github.com/sugarlabs/sugar/tree/master/tests" target="_blank">https://github.com/sugarlabs/sugar/tree/master/tests</a><br><a href="https://github.com/sugarlabs/sugar-build/tree/master/tests" target="_blank">https://github.com/sugarlabs/sugar-build/tree/master/tests</a><br>
<br></div></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On 17 May 2013 15:16, Simon Schampijer <span dir="ltr"><<a href="mailto:simon@schampijer.de" target="_blank">simon@schampijer.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How does the test coverage looks like? Human testing or automated tests?<br>
<br>
Thanks,<br>
Simon<div><div><br>
<br>
On 05/17/2013 03:13 PM, Daniel Narvaez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Simon, Manuel,<br>
<br>
any feedback about this? I see a few possible levels<br>
<br>
1 Everything, bugfixes included<br>
2 Every feature patch<br>
3 Every patch to the new html/javascript code<br>
4 Nothing, leave it to the contributor willingness<br>
<br>
I'm opposed to 4 :) I tend to think we should do 2, because a lot of new<br>
code is landing and the more code without tests we need to maintain the<br>
worst the quality situation will get. I guess 3 would also be a possibility<br>
if we want to try it out and increase gradually.<br>
<br>
<br>
On 13 May 2013 00:28, Daniel Narvaez <<a href="mailto:dwnarvaez@gmail.com" target="_blank">dwnarvaez@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I'd like to propose to make it a requirement, enforced by code reviews, to<br>
provide good test coverage when submitting new code. It will raise the bar<br>
for contributions but it's essential if we want to improve quality (and I<br>
think we have to). I can add a paragraph about it to sugar-docs, if we have<br>
consensus.<br>
<br>
A few details:<br>
<br>
* What to do with patches which have been already submitted? I think it<br>
really depends on the patch, so I'd leave it to the reviewer discretion.<br>
* Should this apply to bug fixes? I tend to think it should, we are not in<br>
a particularly active bug fixing period now, so it's a good time to start<br>
with those too.<br>
* Cannot apply to javascript code yet, because the infra is not in place.<br>
Though writing the infra is on the short time priorities, so this should<br>
change soon.<br>
* Cannot apply to activities because we are missing infra bits. It would<br>
not be too hard to add them, but I think we should focus on html activities<br>
now.<br>
<br>
<br>
--<br>
Daniel Narvaez<br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span><font color="#888888">-- <br>Daniel Narvaez<br>
</font></span></div>
<br></div></div><div class="im">_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br>Daniel Narvaez<br>
</div>