Re: [Elementary-dev-community] Congratulations Luna developers!

[Albert Palacios]

Hi Craig,

Thanks for your explanation and the linked video. I am still agnostic, but
I don't want to be the only one who complained about the proposal.

At this point I have more questions than answers, and those will probably
be solved with a working example.

But remember, *TDD is a development methodology* not a testing methodology.
It will change our development work flow, and will probably move potential
volunteers away from the project.

TDD like every other development methodology does not fit every project or
team. It can be a hit, and it can even the death of the project.

Albert




On Tue, Aug 20, 2013 at 12:50 AM, Craig  wrote:

> 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, Au

Re: [Elementary-dev-community] Media Coverage on elementary OS Luna

[cameron]

Linux Action Show covered LAS in their most recent episode. 
http://www.youtube.com/watch?v=J5hH-L1hC_U


On Mon, Aug 12, 2013 at 9:55 AM, David Gomes  
wrote:

Hello everyone,

Hopefully we'll start getting some media coverage, reviews, blog 
posts and other comments on this release. As some of you might know, 
feedback is very important to us. Therefore, we're working on a list 
of reviews, blog posts and discussions on Luna:


https://docs.google.com/a/elementaryos.org/document/d/1OUN9aZbtPRX4iP-F4kmsEXQpSwWoI95IAUUA54kuySw/edit

Feel free to reply here or comment on there with relevant pages you 
find.


Thank you and best regards,
David "Munchor" Gomes

-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Congratulations Luna developers!

[Craig]

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 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  wrote:
>
>> Count me in.
>>

Re: [Elementary-dev-community] Congratulations Luna developers!

[Gufran]

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 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  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  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 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 
 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 
> 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 <
>> optimi...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Before talking about testing, and advanced development techniques
>>> for teams wi

Re: [Elementary-dev-community] Congratulations Luna developers!

[Albert Palacios]

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  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  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 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 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 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 <
> optimi...@gmail.com> 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@lists.launchpad.net
>> 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@lists.launchpad.net
>>> 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@lists.launchpad.net
>> 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : element

Re: [Elementary-dev-community] Congratulations Luna developers!

[Gufran]

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  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 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 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 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 <
 optimi...@gmail.com> 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@lists.launchpad.net
> 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@lists.launchpad.net
>> 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@lists.launchpad.net
> 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Congratulations Luna developers!

[Craig]

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 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 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 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 <
>>> optimi...@gmail.com> 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@lists.launchpad.net
 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@lists.launchpad.net
> 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Congratulations Luna developers!

[Albert Palacios]

Also,

Adding easy tips into the guide, such as teaching on how to install project
dependencies:

sudo apt-get build-dep wingpanel

Or how to make a "merge" or one "push", can save several hours to
volunteers trying to help.


On Mon, Aug 19, 2013 at 7:05 PM, David Gomes  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 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 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 <
>>> optimi...@gmail.com> 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@lists.launchpad.net
 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Congratulations Luna developers!

[David Gomes]

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 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 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 <
>> optimi...@gmail.com> 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@lists.launchpad.net
>>> 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Congratulations Luna developers!

[Albert Palacios]

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  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 <
> optimi...@gmail.com> 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@lists.launchpad.net
>> 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Congratulations Luna developers!

[David Gomes]

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 <
optimi...@gmail.com> 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@lists.launchpad.net
> 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Congratulations Luna developers!

[Dennis Andres Infantas Reaño]

We could use this project https://fedorahosted.org/dogtail/, it's not VALA,
but being python it should be easy.
An most of all its an alive project.


2013/8/19 Albert Palacios Jimenez 

> 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>



-- 
ðÐennis Andres Infantas Reaño

"The greatness of a nation and its moral progress can judged by the way its
animal area treated"
"La grandeza de una nación y su progreso moral puede ser juzgado por la
forma que sus animales son tratados" Mahatma Gandhi (1869-1948)
"Poderoso no es el que más vidas destruye, sino aquel que las crea, sana y
cuida."
-- 
Mailing list: https://launchpad.net/~elementary-dev-community
Post to : elementary-dev-community@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Congratulations Luna developers!

[Albert Palacios Jimenez]

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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~elementary-dev-community
More help   : https://help.launchpad.net/ListHelp

Re: [Elementary-dev-community] Congratulations Luna developers!

[Alex Lourie]

Right.

1. The code tests another piece of code.
2. You specify it with a set of 'trial' inputs.
  a) you expect the 'correct' inputs to work correctly.
  b) you expect the 'incorrect' inputs to fail gracefully.


On Mon, Aug 19, 2013 at 12:07 PM, A. "Xylon" V.  wrote:

> So if I understand correctly, in TDD there is a specific bit of code (lets
> call it C) that you build a test for. Then, instead of using the
> application and trying to trigger code C, you invoke the test which
> directly calls code C and then reports a result based on whatever input you
> gave it, right?
> On Aug 19, 2013 9:43 AM, "Alex Lourie"  wrote:
>
>> Correct.
>>
>>
>> On Mon, Aug 19, 2013 at 11:27 AM, David Gomes wrote:
>>
>>> So say this code for example:
>>>
>>>
>>> http://bazaar.launchpad.net/~elementary-apps/pantheon-terminal/trunk/view/head:/src/TerminalWidget.vala#L37
>>>
>>> Sometimes we have some issues with ReGex (see
>>> https://code.launchpad.net/~voldyman/pantheon-terminal/colon-fixed/+merge/180735
>>> ).
>>>
>>> Is that the kind of thing we can use TDD for? Like have a bunch of URLs
>>> and see if Terminal detects them or not without any GUI, just terminal
>>> Found/Not Found messages?
>>>
>>> ~David "Munchor" Gomes
>>>
>>>
>>> On Mon, Aug 19, 2013 at 1:38 AM, Craig  wrote:
>>>
 David,

 I understand and appreciate the difficulty; however, I've had exactly
 zero questions about TDD. Like I said in the original post, I'm happy to
 answer any questions you may have.

 Please take me up on that offer any time.

 Thanks,
 Craig
 On Aug 18, 2013 6:57 PM, "David Gomes"  wrote:

> This, this and this.
>
> And also many of the developers like me aren't really experienced with
> TDD and will have to take some time to study, learn and adapt to it. You
> can't just come here and tell developers, many of whom inexperienced young
> amateur programmers, to start using TDDs. Take me, for example, I never 
> had
> proper programming education, I'm 17 years old. I know what TDD is but 
> I've
> never used it before. You have to understand TDD is something very
> enterprise-ish and "professional" that "big serious" companies do.
>
> Look, I'm not saying we can't do it or we shouldn't do it or we won't
> do it - I'm just saying you need a better approach to what you're doing. I
> realize how useful and important TDD can be, but many of us might just be
> too busy having fun.
>
> Regards,
> David
>
> PS. I really hope I wasn't rude, I mean all I said in the nicest of
> ways.
>
>
>
> On Sun, Aug 18, 2013 at 11:58 PM, Daniel Foré  > wrote:
>
>> This all sounds great and I think everybody is pro-testing, however
>> I've yet to see a reproduce-able example or a guide regarding any kind of
>> tests being implemented (especially by those extremely vocal about their
>> importance). Not books or articles about why testing is good, but 
>> something
>> that actually shows a person how to write tests for their apps.
>>
>> So, as Linus would say, "Talk is cheap. Show me the code."
>> —
>> Sent from Mailbox  for iPhone
>>
>>
>> On Sun, Aug 18, 2013 at 3:47 PM, Craig  wrote:
>>
>>> Hi Alex,
>>>
>>> tl;dr: Unit tests are pretty much necessary to have an architecture
>>> on which you can run automatic system-level tests, and if you aren't
>>> automating then testing becomes too impractical.
>>>
>>> When you describe "system tests" you are actually describing what
>>> are called "acceptance tests" or "behavioral" tests (
>>> http://www.extremeprogramming.org/rules/functionaltests.html). Unit
>>> tests test small units of code such as classes or functions. Traditional
>>> TDD relies primarily upon unit tests, and those are primarily what I'm
>>> referring to.
>>>
>>> One of the primary purposes of unit testing is to ensure good code
>>> architecture. If you don't unit test, you probably won't have good 
>>> access
>>> points for your acceptance tests (how do you verify that that Gtk.Label 
>>> has
>>> the correct text when you can only access the top level window?), so
>>> automation will be out of the question. And if you aren't automating 
>>> then
>>> you can't continuously integrate (running all tests every time a change 
>>> is
>>> made to the repository in order to find bugs as soon as they are made).
>>> Honestly, if you aren't automating then testing becomes too impractical.
>>> On Aug 18, 2013 5:10 PM, "Alex Lourie"  wrote:
>>>
 Hi Craig

 For the clarification purposes, I'd like to separate 'automatic
 tests (system testst)' and 'unittests'. I consider them different 
 things.
 Unittests are pieces of code that test some other pieces of the code.

Re: [Elementary-dev-community] Congratulations Luna developers!

[Gufran]

Yes exactly.
That is how tests works.
On Aug 19, 2013 2:37 PM, "A. "Xylon" V."  wrote:

> So if I understand correctly, in TDD there is a specific bit of code (lets
> call it C) that you build a test for. Then, instead of using the
> application and trying to trigger code C, you invoke the test which
> directly calls code C and then reports a result based on whatever input you
> gave it, right?
> On Aug 19, 2013 9:43 AM, "Alex Lourie"  wrote:
>
>> Correct.
>>
>>
>> On Mon, Aug 19, 2013 at 11:27 AM, David Gomes wrote:
>>
>>> So say this code for example:
>>>
>>>
>>> http://bazaar.launchpad.net/~elementary-apps/pantheon-terminal/trunk/view/head:/src/TerminalWidget.vala#L37
>>>
>>> Sometimes we have some issues with ReGex (see
>>> https://code.launchpad.net/~voldyman/pantheon-terminal/colon-fixed/+merge/180735
>>> ).
>>>
>>> Is that the kind of thing we can use TDD for? Like have a bunch of URLs
>>> and see if Terminal detects them or not without any GUI, just terminal
>>> Found/Not Found messages?
>>>
>>> ~David "Munchor" Gomes
>>>
>>>
>>> On Mon, Aug 19, 2013 at 1:38 AM, Craig  wrote:
>>>
 David,

 I understand and appreciate the difficulty; however, I've had exactly
 zero questions about TDD. Like I said in the original post, I'm happy to
 answer any questions you may have.

 Please take me up on that offer any time.

 Thanks,
 Craig
 On Aug 18, 2013 6:57 PM, "David Gomes"  wrote:

> This, this and this.
>
> And also many of the developers like me aren't really experienced with
> TDD and will have to take some time to study, learn and adapt to it. You
> can't just come here and tell developers, many of whom inexperienced young
> amateur programmers, to start using TDDs. Take me, for example, I never 
> had
> proper programming education, I'm 17 years old. I know what TDD is but 
> I've
> never used it before. You have to understand TDD is something very
> enterprise-ish and "professional" that "big serious" companies do.
>
> Look, I'm not saying we can't do it or we shouldn't do it or we won't
> do it - I'm just saying you need a better approach to what you're doing. I
> realize how useful and important TDD can be, but many of us might just be
> too busy having fun.
>
> Regards,
> David
>
> PS. I really hope I wasn't rude, I mean all I said in the nicest of
> ways.
>
>
>
> On Sun, Aug 18, 2013 at 11:58 PM, Daniel Foré  > wrote:
>
>> This all sounds great and I think everybody is pro-testing, however
>> I've yet to see a reproduce-able example or a guide regarding any kind of
>> tests being implemented (especially by those extremely vocal about their
>> importance). Not books or articles about why testing is good, but 
>> something
>> that actually shows a person how to write tests for their apps.
>>
>> So, as Linus would say, "Talk is cheap. Show me the code."
>> —
>> Sent from Mailbox  for iPhone
>>
>>
>> On Sun, Aug 18, 2013 at 3:47 PM, Craig  wrote:
>>
>>> Hi Alex,
>>>
>>> tl;dr: Unit tests are pretty much necessary to have an architecture
>>> on which you can run automatic system-level tests, and if you aren't
>>> automating then testing becomes too impractical.
>>>
>>> When you describe "system tests" you are actually describing what
>>> are called "acceptance tests" or "behavioral" tests (
>>> http://www.extremeprogramming.org/rules/functionaltests.html). Unit
>>> tests test small units of code such as classes or functions. Traditional
>>> TDD relies primarily upon unit tests, and those are primarily what I'm
>>> referring to.
>>>
>>> One of the primary purposes of unit testing is to ensure good code
>>> architecture. If you don't unit test, you probably won't have good 
>>> access
>>> points for your acceptance tests (how do you verify that that Gtk.Label 
>>> has
>>> the correct text when you can only access the top level window?), so
>>> automation will be out of the question. And if you aren't automating 
>>> then
>>> you can't continuously integrate (running all tests every time a change 
>>> is
>>> made to the repository in order to find bugs as soon as they are made).
>>> Honestly, if you aren't automating then testing becomes too impractical.
>>> On Aug 18, 2013 5:10 PM, "Alex Lourie"  wrote:
>>>
 Hi Craig

 For the clarification purposes, I'd like to separate 'automatic
 tests (system testst)' and 'unittests'. I consider them different 
 things.
 Unittests are pieces of code that test some other pieces of the code.
 System tests are scripts/code/steps that test that your program (or 
 part of
 it) works. Unittests are usually run automatically (by, say, 
 unittes

Re: [Elementary-dev-community] Congratulations Luna developers!

[A. "Xylon" V.]

So if I understand correctly, in TDD there is a specific bit of code (lets
call it C) that you build a test for. Then, instead of using the
application and trying to trigger code C, you invoke the test which
directly calls code C and then reports a result based on whatever input you
gave it, right?
On Aug 19, 2013 9:43 AM, "Alex Lourie"  wrote:

> Correct.
>
>
> On Mon, Aug 19, 2013 at 11:27 AM, David Gomes wrote:
>
>> So say this code for example:
>>
>>
>> http://bazaar.launchpad.net/~elementary-apps/pantheon-terminal/trunk/view/head:/src/TerminalWidget.vala#L37
>>
>> Sometimes we have some issues with ReGex (see
>> https://code.launchpad.net/~voldyman/pantheon-terminal/colon-fixed/+merge/180735
>> ).
>>
>> Is that the kind of thing we can use TDD for? Like have a bunch of URLs
>> and see if Terminal detects them or not without any GUI, just terminal
>> Found/Not Found messages?
>>
>> ~David "Munchor" Gomes
>>
>>
>> On Mon, Aug 19, 2013 at 1:38 AM, Craig  wrote:
>>
>>> David,
>>>
>>> I understand and appreciate the difficulty; however, I've had exactly
>>> zero questions about TDD. Like I said in the original post, I'm happy to
>>> answer any questions you may have.
>>>
>>> Please take me up on that offer any time.
>>>
>>> Thanks,
>>> Craig
>>> On Aug 18, 2013 6:57 PM, "David Gomes"  wrote:
>>>
 This, this and this.

 And also many of the developers like me aren't really experienced with
 TDD and will have to take some time to study, learn and adapt to it. You
 can't just come here and tell developers, many of whom inexperienced young
 amateur programmers, to start using TDDs. Take me, for example, I never had
 proper programming education, I'm 17 years old. I know what TDD is but I've
 never used it before. You have to understand TDD is something very
 enterprise-ish and "professional" that "big serious" companies do.

 Look, I'm not saying we can't do it or we shouldn't do it or we won't
 do it - I'm just saying you need a better approach to what you're doing. I
 realize how useful and important TDD can be, but many of us might just be
 too busy having fun.

 Regards,
 David

 PS. I really hope I wasn't rude, I mean all I said in the nicest of
 ways.



 On Sun, Aug 18, 2013 at 11:58 PM, Daniel Foré 
 wrote:

> This all sounds great and I think everybody is pro-testing, however
> I've yet to see a reproduce-able example or a guide regarding any kind of
> tests being implemented (especially by those extremely vocal about their
> importance). Not books or articles about why testing is good, but 
> something
> that actually shows a person how to write tests for their apps.
>
> So, as Linus would say, "Talk is cheap. Show me the code."
> —
> Sent from Mailbox  for iPhone
>
>
> On Sun, Aug 18, 2013 at 3:47 PM, Craig  wrote:
>
>> Hi Alex,
>>
>> tl;dr: Unit tests are pretty much necessary to have an architecture
>> on which you can run automatic system-level tests, and if you aren't
>> automating then testing becomes too impractical.
>>
>> When you describe "system tests" you are actually describing what are
>> called "acceptance tests" or "behavioral" tests (
>> http://www.extremeprogramming.org/rules/functionaltests.html). Unit
>> tests test small units of code such as classes or functions. Traditional
>> TDD relies primarily upon unit tests, and those are primarily what I'm
>> referring to.
>>
>> One of the primary purposes of unit testing is to ensure good code
>> architecture. If you don't unit test, you probably won't have good access
>> points for your acceptance tests (how do you verify that that Gtk.Label 
>> has
>> the correct text when you can only access the top level window?), so
>> automation will be out of the question. And if you aren't automating then
>> you can't continuously integrate (running all tests every time a change 
>> is
>> made to the repository in order to find bugs as soon as they are made).
>> Honestly, if you aren't automating then testing becomes too impractical.
>> On Aug 18, 2013 5:10 PM, "Alex Lourie"  wrote:
>>
>>> Hi Craig
>>>
>>> For the clarification purposes, I'd like to separate 'automatic
>>> tests (system testst)' and 'unittests'. I consider them different 
>>> things.
>>> Unittests are pieces of code that test some other pieces of the code.
>>> System tests are scripts/code/steps that test that your program (or 
>>> part of
>>> it) works. Unittests are usually run automatically (by, say, unittesting
>>> framework). System tests could be run automatically or manually. There 
>>> are,
>>> sometimes, frameworks for that, but in most cases it's either manual or
>>> custom developed.
>>>
>>> Unittests are (usually) develope

Re: [Elementary-dev-community] Congratulations Luna developers!

[Alex Lourie]

Correct.


On Mon, Aug 19, 2013 at 11:27 AM, David Gomes wrote:

> So say this code for example:
>
>
> http://bazaar.launchpad.net/~elementary-apps/pantheon-terminal/trunk/view/head:/src/TerminalWidget.vala#L37
>
> Sometimes we have some issues with ReGex (see
> https://code.launchpad.net/~voldyman/pantheon-terminal/colon-fixed/+merge/180735
> ).
>
> Is that the kind of thing we can use TDD for? Like have a bunch of URLs
> and see if Terminal detects them or not without any GUI, just terminal
> Found/Not Found messages?
>
> ~David "Munchor" Gomes
>
>
> On Mon, Aug 19, 2013 at 1:38 AM, Craig  wrote:
>
>> David,
>>
>> I understand and appreciate the difficulty; however, I've had exactly
>> zero questions about TDD. Like I said in the original post, I'm happy to
>> answer any questions you may have.
>>
>> Please take me up on that offer any time.
>>
>> Thanks,
>> Craig
>> On Aug 18, 2013 6:57 PM, "David Gomes"  wrote:
>>
>>> This, this and this.
>>>
>>> And also many of the developers like me aren't really experienced with
>>> TDD and will have to take some time to study, learn and adapt to it. You
>>> can't just come here and tell developers, many of whom inexperienced young
>>> amateur programmers, to start using TDDs. Take me, for example, I never had
>>> proper programming education, I'm 17 years old. I know what TDD is but I've
>>> never used it before. You have to understand TDD is something very
>>> enterprise-ish and "professional" that "big serious" companies do.
>>>
>>> Look, I'm not saying we can't do it or we shouldn't do it or we won't do
>>> it - I'm just saying you need a better approach to what you're doing. I
>>> realize how useful and important TDD can be, but many of us might just be
>>> too busy having fun.
>>>
>>> Regards,
>>> David
>>>
>>> PS. I really hope I wasn't rude, I mean all I said in the nicest of ways.
>>>
>>>
>>>
>>> On Sun, Aug 18, 2013 at 11:58 PM, Daniel Foré 
>>> wrote:
>>>
 This all sounds great and I think everybody is pro-testing, however
 I've yet to see a reproduce-able example or a guide regarding any kind of
 tests being implemented (especially by those extremely vocal about their
 importance). Not books or articles about why testing is good, but something
 that actually shows a person how to write tests for their apps.

 So, as Linus would say, "Talk is cheap. Show me the code."
 —
 Sent from Mailbox  for iPhone


 On Sun, Aug 18, 2013 at 3:47 PM, Craig  wrote:

> Hi Alex,
>
> tl;dr: Unit tests are pretty much necessary to have an architecture on
> which you can run automatic system-level tests, and if you aren't
> automating then testing becomes too impractical.
>
> When you describe "system tests" you are actually describing what are
> called "acceptance tests" or "behavioral" tests (
> http://www.extremeprogramming.org/rules/functionaltests.html). Unit
> tests test small units of code such as classes or functions. Traditional
> TDD relies primarily upon unit tests, and those are primarily what I'm
> referring to.
>
> One of the primary purposes of unit testing is to ensure good code
> architecture. If you don't unit test, you probably won't have good access
> points for your acceptance tests (how do you verify that that Gtk.Label 
> has
> the correct text when you can only access the top level window?), so
> automation will be out of the question. And if you aren't automating then
> you can't continuously integrate (running all tests every time a change is
> made to the repository in order to find bugs as soon as they are made).
> Honestly, if you aren't automating then testing becomes too impractical.
> On Aug 18, 2013 5:10 PM, "Alex Lourie"  wrote:
>
>> Hi Craig
>>
>> For the clarification purposes, I'd like to separate 'automatic tests
>> (system testst)' and 'unittests'. I consider them different things.
>> Unittests are pieces of code that test some other pieces of the code.
>> System tests are scripts/code/steps that test that your program (or part 
>> of
>> it) works. Unittests are usually run automatically (by, say, unittesting
>> framework). System tests could be run automatically or manually. There 
>> are,
>> sometimes, frameworks for that, but in most cases it's either manual or
>> custom developed.
>>
>> Unittests are (usually) developed by the same developer who developed
>> the original code, just as in your TDD example. System tests are best
>> developed by external party (such as users).
>>
>> From here on, I can agree with you on point 1, and the naming.
>>
>> Basically, we all agree that having *testing *is a good practice and
>> a feasible way to manage the complexity of software. But unittesting 
>> cannot
>> test the logical connections between the blocks of code in the pr

Re: [Elementary-dev-community] Congratulations Luna developers!

[David Gomes]

So say this code for example:

http://bazaar.launchpad.net/~elementary-apps/pantheon-terminal/trunk/view/head:/src/TerminalWidget.vala#L37

Sometimes we have some issues with ReGex (see
https://code.launchpad.net/~voldyman/pantheon-terminal/colon-fixed/+merge/180735
).

Is that the kind of thing we can use TDD for? Like have a bunch of URLs and
see if Terminal detects them or not without any GUI, just terminal
Found/Not Found messages?

~David "Munchor" Gomes


On Mon, Aug 19, 2013 at 1:38 AM, Craig  wrote:

> David,
>
> I understand and appreciate the difficulty; however, I've had exactly zero
> questions about TDD. Like I said in the original post, I'm happy to answer
> any questions you may have.
>
> Please take me up on that offer any time.
>
> Thanks,
> Craig
> On Aug 18, 2013 6:57 PM, "David Gomes"  wrote:
>
>> This, this and this.
>>
>> And also many of the developers like me aren't really experienced with
>> TDD and will have to take some time to study, learn and adapt to it. You
>> can't just come here and tell developers, many of whom inexperienced young
>> amateur programmers, to start using TDDs. Take me, for example, I never had
>> proper programming education, I'm 17 years old. I know what TDD is but I've
>> never used it before. You have to understand TDD is something very
>> enterprise-ish and "professional" that "big serious" companies do.
>>
>> Look, I'm not saying we can't do it or we shouldn't do it or we won't do
>> it - I'm just saying you need a better approach to what you're doing. I
>> realize how useful and important TDD can be, but many of us might just be
>> too busy having fun.
>>
>> Regards,
>> David
>>
>> PS. I really hope I wasn't rude, I mean all I said in the nicest of ways.
>>
>>
>>
>> On Sun, Aug 18, 2013 at 11:58 PM, Daniel Foré wrote:
>>
>>> This all sounds great and I think everybody is pro-testing, however I've
>>> yet to see a reproduce-able example or a guide regarding any kind of tests
>>> being implemented (especially by those extremely vocal about their
>>> importance). Not books or articles about why testing is good, but something
>>> that actually shows a person how to write tests for their apps.
>>>
>>> So, as Linus would say, "Talk is cheap. Show me the code."
>>> —
>>> Sent from Mailbox  for iPhone
>>>
>>>
>>> On Sun, Aug 18, 2013 at 3:47 PM, Craig  wrote:
>>>
 Hi Alex,

 tl;dr: Unit tests are pretty much necessary to have an architecture on
 which you can run automatic system-level tests, and if you aren't
 automating then testing becomes too impractical.

 When you describe "system tests" you are actually describing what are
 called "acceptance tests" or "behavioral" tests (
 http://www.extremeprogramming.org/rules/functionaltests.html). Unit
 tests test small units of code such as classes or functions. Traditional
 TDD relies primarily upon unit tests, and those are primarily what I'm
 referring to.

 One of the primary purposes of unit testing is to ensure good code
 architecture. If you don't unit test, you probably won't have good access
 points for your acceptance tests (how do you verify that that Gtk.Label has
 the correct text when you can only access the top level window?), so
 automation will be out of the question. And if you aren't automating then
 you can't continuously integrate (running all tests every time a change is
 made to the repository in order to find bugs as soon as they are made).
 Honestly, if you aren't automating then testing becomes too impractical.
 On Aug 18, 2013 5:10 PM, "Alex Lourie"  wrote:

> Hi Craig
>
> For the clarification purposes, I'd like to separate 'automatic tests
> (system testst)' and 'unittests'. I consider them different things.
> Unittests are pieces of code that test some other pieces of the code.
> System tests are scripts/code/steps that test that your program (or part 
> of
> it) works. Unittests are usually run automatically (by, say, unittesting
> framework). System tests could be run automatically or manually. There 
> are,
> sometimes, frameworks for that, but in most cases it's either manual or
> custom developed.
>
> Unittests are (usually) developed by the same developer who developed
> the original code, just as in your TDD example. System tests are best
> developed by external party (such as users).
>
> From here on, I can agree with you on point 1, and the naming.
>
> Basically, we all agree that having *testing *is a good practice and
> a feasible way to manage the complexity of software. But unittesting 
> cannot
> test the logical connections between the blocks of code in the program.
> That's the job for system testing.
>
> I don't care how we call it. The more *systematic *testing we do for
> Elementary the better it's going to be, and the more chances we ha