[Sugar-devel] Requiring test coverage for new code

Daniel Narvaez dwnarvaez at gmail.com
Fri May 17 09:45:02 EDT 2013


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.

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.

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


On 17 May 2013 15:36, Gonzalo Odiard <gonzalo at laptop.org> wrote:

> May be I am old fashion, but requesting mandatory automated tests for all
> the changes is not a good idea.
> We are a small team. And we don't have a problem of regressions.
> May be, with the new  web api, with the many changes we will have in the
> next months,
> is a good idea.
>
> Gonzalo
>
>
> On Fri, May 17, 2013 at 10:23 AM, Daniel Narvaez <dwnarvaez at gmail.com>wrote:
>
>> 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
>>
>> https://github.com/sugarlabs/sugar-toolkit-gtk3/tree/master/tests
>> https://github.com/sugarlabs/sugar/tree/master/tests
>> https://github.com/sugarlabs/sugar-build/tree/master/tests
>>
>>
>>
>> On 17 May 2013 15:16, Simon Schampijer <simon at schampijer.de> wrote:
>>
>>> How does the test coverage looks like? Human testing or automated tests?
>>>
>>> Thanks,
>>>    Simon
>>>
>>>
>>> On 05/17/2013 03:13 PM, Daniel Narvaez wrote:
>>>
>>>> Simon, Manuel,
>>>>
>>>> any feedback about this? I see a few possible levels
>>>>
>>>> 1 Everything, bugfixes included
>>>> 2 Every feature patch
>>>> 3 Every patch to the new html/javascript code
>>>> 4 Nothing, leave it to the contributor willingness
>>>>
>>>> I'm opposed to 4 :) I tend to think we should do 2, because a lot of new
>>>> code is landing and the more code without tests we need to maintain the
>>>> worst the quality situation will get. I guess 3 would also be a
>>>> possibility
>>>> if we want to try it out and increase gradually.
>>>>
>>>>
>>>> On 13 May 2013 00:28, Daniel Narvaez <dwnarvaez at gmail.com> wrote:
>>>>
>>>>  Hello,
>>>>>
>>>>> I'd like to propose to make it a requirement, enforced by code
>>>>> reviews, to
>>>>> provide good test coverage when submitting new code. It will raise the
>>>>> bar
>>>>> for contributions but it's essential if we want to improve quality
>>>>> (and I
>>>>> think we have to). I can add a paragraph about it to sugar-docs, if we
>>>>> have
>>>>> consensus.
>>>>>
>>>>> A few details:
>>>>>
>>>>> * What to do with patches which have been already submitted? I think it
>>>>> really depends on the patch, so I'd leave it to the reviewer
>>>>> discretion.
>>>>> * Should this apply to bug fixes? I tend to think it should, we are
>>>>> not in
>>>>> a particularly active bug fixing period now, so it's a good time to
>>>>> start
>>>>> with those too.
>>>>> * Cannot apply to javascript code yet, because the infra is not in
>>>>> place.
>>>>> Though writing the infra is on the short time priorities, so this
>>>>> should
>>>>> change soon.
>>>>> * Cannot apply to activities because we are missing infra bits. It
>>>>> would
>>>>> not be too hard to add them, but I think we should focus on html
>>>>> activities
>>>>> now.
>>>>>
>>>>>
>>>>> --
>>>>> Daniel Narvaez
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Daniel Narvaez
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>


-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130517/34206e26/attachment.html>


More information about the Sugar-devel mailing list