<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">https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests</a><br>
<a href="https://github.com/sugarlabs/sugar/tree/master/tests">https://github.com/sugarlabs/sugar/tree/master/tests</a><br><a href="https://github.com/sugarlabs/sugar-build/tree/master/tests">https://github.com/sugarlabs/sugar-build/tree/master/tests</a><br>
<br></div></div><div class="gmail_extra"><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 class="HOEnZb"><div class="h5"><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>-- <br>Daniel Narvaez<br>
</div>