← Back to team overview

elementary-dev-community team mailing list archive

Re: Congratulations Luna developers!

 

Hi Albert,
First off, I agree with you that TDD will add extra efforts and
complexities. Yes I agree that there will be more tools to know and
maintain and Yes, there is no guarantee that TDD will eliminate all bugs.
In fact, here is a video worth watching http://vimeo.com/68375232

Now, I'm completely in favor of TDD anyways.
I am not saying that there should be a full fledged test suite shipped with
codes but unit tests are a good way to reduce a lot of bugs. As long as you
can tell that all the units are working properly you can almost guarantee
that integration will pass in given environment.
Regarding the concern about benefit in time and resources, TDD has a steep
learning curve, lets add the learning curve of Vala as well, so new comers
will definitely have a hard time starting off with some project but once
you get a hold of testing tools and language you will fly.
Again, tests itself might be buggy and that will ruin the entire thing so
that is why we need some guidelines on how to cap the test logic and what
not to test. Of course no one is stopping you from writing a thousand lines
of test codes for every bit and nibble you used in a software but that is
not the way we unit test.

Incomplete projects are a whole different story, I cant really comment
about why Granite is not yet furnished or why the docs are missing but yes
I can tell that if we include TDD (Unit testing to be precise) in
development cycle and provide a controlled environment for developers to
test *(ie. just dont go mad over the entire piece of codes you've written
but concentrate on the part which is worth testing and more error
prone)*there will be no bugs to survive the release. One ladder at a
time and we
put together the pieces to make it large.

Regards.


On Mon, Aug 19, 2013 at 11:02 PM, Albert Palacios <optimisme@xxxxxxxxx>wrote:

> Hi Craig and Gufran,
>
> I don't agree with TDD, and making a committee. Can you prove that there
> will be huge benefits in time/resources? Can you prove that there will be
> less bugs? (looks like that if tests are not right, bugs will populate
> equally). Can you prove that creating, modifying and fixing code is going
> to be easier?
>
> From what's been said, looks like there will be an extra effort on
> development, adding complexity and more tools to know (not to say
> maintain).  Can we focus on the half done things before adding new
> projects? Granite is not ready, documentation is missing, not to talk about
> the bugs that survived Luna release ...
>
>
> On Mon, Aug 19, 2013 at 7:27 PM, Gufran <dogabhai@xxxxxxxxx> wrote:
>
>> Count me in.
>> I cant really put forward any point on how should we proceed but I'd
>> definitely love to be with the team.
>> Yes, a *testing committee* is a good idea, maybe something independent
>> of dev community. We can write scripts to automate tests, and we can do
>> that in any language (Python for example), so it would be like a Python
>> coupling between software and tests.
>> Just my two cents :)
>>
>>
>>
>> On Mon, Aug 19, 2013 at 10:43 PM, Craig <weberc2@xxxxxxxxx> wrote:
>>
>>> This is cool and important, but I don't think it should stop the
>>> discussion on test driven development. Perhaps this could be a separate
>>> thread? It doesn't sound as though anyone is opposed to TDD, so can we
>>> confirm that? And if no one is opposed, how can we proceed? Can we start
>>> some kind of a "testing committee" to help determine what testing steps are
>>> needed, what framework to use, and how to integrate testing into the
>>> existing project structure (i.e., using CMake)?
>>>
>>> Does this sound like a good plan? Thoughts?
>>>
>>>
>>> On Mon, Aug 19, 2013 at 12:05 PM, David Gomes <david@xxxxxxxxxxxxxxxx>wrote:
>>>
>>>> I'll work on it, so far we only have this I made:
>>>> https://dl.dropboxusercontent.com/u/19899464/reviewstutorial.html
>>>>
>>>>
>>>> On Mon, Aug 19, 2013 at 6:01 PM, Albert Palacios <optimisme@xxxxxxxxx>wrote:
>>>>
>>>>> Hi Munchor,
>>>>>
>>>>> A contribution / bug fixing step by step guide is needed at the
>>>>> developers site. There was a .pdf before the new site change, but now it is
>>>>> impossible to find.
>>>>>
>>>>>  The problem with the old guide is that it encouraged to create your
>>>>> own branch instead of using the ~elementary-dev-community one (this is
>>>>> totally new for me). Obviously, bazaar guides doesn't teach you on using
>>>>> the "elementary-dev-community".
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 19, 2013 at 6:57 PM, David Gomes <david@xxxxxxxxxxxxxxxx>wrote:
>>>>>
>>>>>> I always tell people if they make their branches owned by
>>>>>> ~elementary-dev-community I will volunteer to fix the code style myself. I
>>>>>> have all the free time and the will to do it, just people always make their
>>>>>> branches owned by themselves.
>>>>>>
>>>>>> ~David "Munchor" Gomes
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 19, 2013 at 4:29 PM, Albert Palacios Jimenez <
>>>>>> optimisme@xxxxxxxxx> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Before talking about testing, and advanced development techniques
>>>>>>> for teams with resources, there is one easy and simple thing we can do to
>>>>>>> accelerate development.
>>>>>>>
>>>>>>> Sometimes (very often), bugs are stopped due spaces not following
>>>>>>> the "code style" guidelines. Adding a "code style" validator script before
>>>>>>> compiling, we can prevent uploads with spaces at the end of the lines ...
>>>>>>>  and save a lot of time.
>>>>>>>
>>>>>>> For example, just executing the next line before compiling:
>>>>>>>
>>>>>>> find . -type f -print0 | xargs -0 sed -i 's/[ \t]*$//'
>>>>>>>
>>>>>>> We will remove every "white space" at the end of any line, including
>>>>>>> new lines with tab spaces.
>>>>>>>
>>>>>>> This can sound stupid, but it is absurd to block bug fixes during
>>>>>>> several days due white spaces at the end of lines.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~elementary-dev-community
>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>

References