elementary-dev-community team mailing list archive

[Craig <weberc2@xxxxxxxxx>]

Hi Albert,

Thanks for your response, you asked a lot of great questions. In addition
to Gufran's earlier response.

 Can you prove that there will be huge benefits in time/resources?


Well, that depends on what you consider "proof". In the spring, my company
paid several thousand dollars to send me to a conference in San Jose in
which many software development authorities recited, "test driven
development pays itself off in iteration 0". That means the very first time
you write the code it has already paid for itself (because even before you
get the automatic-regression testing benefits, you've already got the
benefits of a better architecture and documentation--because the tests
_are_ the documentation!). I'm sure I can dig up lots of other resources,
but I think it should suffice to say that I've never heard an expert
comment on TDD except to say it's fastest way to develop quality software.
For more information addressing your specific concerns, see the Wikipedia
article's "benefits" section (and read on to the "shortcomings" as it is
also relevant: http://en.wikipedia.org/wiki/Test-driven_development#Benefits.
Even more importantly, this short video:
http://www.youtube.com/watch?v=DodJQyHsmHI


Can you prove that there will be less bugs? (looks like that if tests are
> not right, bugs will populate equally).

It's pretty hard to write bad tests if you're practicing TDD, because you
write the test first, watch it fail, insert the code you need to make it
pass, and then hopefully watch it pass. If you wrote a bad test, it very
probably will pass before you've written the code to make it pass (which
serves to alert the programmer that his test is bad or his software is
doing something unexpected) or the test will fail after he has correctly
written the next line of code (which serves to alert the programmer to
review both the code and his test and identify the source of the problem).
For this reason alone, many, many bugs are eliminated.

>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).

Besides the initial learning curve, development actually goes _faster_ with
TDD (see the aforementioned Wikipedia article--I can provide more resources
on demand) because debugging time becomes exponentially more expensive as
time passes after the bug has been introduced. This is because the bug can
live anywhere in any code that has been added *since the last time the
tests were run* and because the programmer will have an increasingly
difficult time remembering the code he wrote at the time of the bug as time
progresses. With TDD, you are running the tests after every change
(generally you test every time you build), so as soon as you've broken
something you find out about it. This means that the bug is guaranteed to
live in the last change you made, which is a smaller sample and
fresher-in-your-mind than changes you made weeks ago. Regarding your
complexity concern, generally the process isn't complex (it's actually very
simple) and it _simplifies_ development once you learn how to do it. The
most complex part is figuring out how to integrate testing into the CMake
project, and that's only complicated because CMake is complicated.
Regarding tools, there are already testing tools available for Vala,
including GLib (so we don't have to maintain anything). Anyway, testing
tools don't take a terribly long time to learn.

 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 ...


TDD is more valuable the sooner you start implementing it. Even if you
didn't write tests for old code and only started TDD with new code (and
existing defects), you would be doing yourself a huge favor. I'm not
suggesting that everyone stop what they're doing and go back and test every
line of code (although it would be a good thing to chip away at over time),
but practicing TDD on _new_ code can't hurt that much, can it?

With that in mind, are there any arguments against TDD that outweigh its
merits?

Thanks again for your questions! :)
Craig


On Mon, Aug 19, 2013 at 12:32 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
>>
>>
>