elementary-dev-community team mailing list archive

["Dane Henson (elementary)" <dane@xxxxxxxxxxxxxxxx>]

Craig,
I don't think this is something you can just hand off.  You championed 
this to a 60+ e-mail thread and you just expect someone else to pick up 
the banner?

My old pastor had a saying: "See the need, fill the need."

If you feel this passionate about helping elementary, I know you can 
get over your GoLang tendencies and jump on the Vala bandwagon to at 
least act as a "project manager".

Here are some practical examples that we can start with:
1. The Vala language itself uses Unit testing without a framework, and 
they use a bash script to run them.  Prolific Unit Test experts have 
said that it doesn't matter if you use a framework or not, just test!
https://git.gnome.org/browse/vala/tree/tests

2. I pulled sources from all over the internet to create a half-baked 
project with testing built in using GLib.Test and Gee.TestCase.  This 
has appeared on this mailing list before and could be a reasonable 
beginning.
https://code.launchpad.net/~thegreatdane/+junk/agenda-tests

3. I'm working on a small project that I'll eventually put in a 
repository.  It has the potential to be a good Unit Testing example.

My problem is I need help knowing what is good to test, and what is 
redundant or unnecessary.  We need practical knowledge, and you have 
it!  I would be glad to do a hangout with you sometime (not today 
unfortunately) and get this stuff going.  Don't give up or pass the 
baton.  You brought it up, you need to follow through.

On Thu, Aug 22, 2013 at 12:55 AM, Alex Lourie <djay.il@xxxxxxxxx> wrote:
> Craig
> It seems we're running circles. No leader is needed now aside for 
> someone who starts writing code. How about you choose some an app you 
> consider to be a good start? We then find volunteers. And start 
> coding.
>
> I'm sure that the moment it starts, everyone will be interested in 
> results.
>
> On Aug 22, 2013 3:27 AM, "Craig" <weberc2@xxxxxxxxx> wrote:
> > I'm not opposed; however, every time I've delved into Elementary 
> > development, I've found myself fighting too many tertiary fires 
> > before I'm able to get any real work done (usually it's chasing down 
> > one obscure environment issue or another). So basically, I would 
> > like someone who is competent at Elementary development to 
> > "champion" the project (to serve as its leader) and I and a few 
> > other TDDevelopers can coach the development team as well as help 
> > develop ourselves.
> >
> > Furthermore, this exercise will be more productive if we have other 
> > devs who are interested in learning TDD to participate.
> >
> > So basically, if you can find a few elementary-proficient developers 
> > to help with the elementary-specific problems (including a project 
> > lead), the other TDDevelopers and I can coach and develop along side 
> > them.
> >
> > Thoughts?
> >
> >
> > On Wed, Aug 21, 2013 at 4:50 PM, Kurt Smolderen 
> > <kurt.smolderen@xxxxxxxxxx> wrote:
> > > What do you think of giving Footnote some love? I think it is 
> > > currently unmaintained (need to verify that), it's conceptually a 
> > > rather simple application but offers a good set of practices for 
> > > TDD/ writing tests.
> > >
> > > We need to verify first of course what the intentions of the 
> > > current owner are, but I would personally like to see a new version 
> > > of Footnote...
> > >
> > > Craig <weberc2@xxxxxxxxx> wrote:
> > > > > I have never heard a project die because they decided to move to 
> > > > > TDD. And I heard about lots of hits on the matter.
> > > >
> > > > This. I've heard (and witnessed) a lot of projects drop their 
> > > > defect percentage from 20% to 3%.  A lot of new-to-TDD developers 
> > > > don't like it at first because it feels slower, but I don't think 
> > > > those people remember how much time is spent bug hunting at the 
> > > > end of a release cycle.
> > > >
> > > > I think the next step is to find a pilot project and get the lead 
> > > > developer(s) to agree to work toward TDD. This will probably look 
> > > > like:
> > > >
> > > > 1) Modifying the project structure to include _test directories
> > > > 2) Creating tests with GLib.Test or some such
> > > > 3) Coaching/mentoring the developers at TDD
> > > > 4) Performing code reviews in which insufficiently tested code is 
> > > > sent back for revision
> > > >
> > > > After testing it out for a few months, the community can see how 
> > > > they like it.
> > > >
> > > > Does this sound like a reasonable approach? If so, would any 
> > > > project leads like to volunteer their project? And who in the 
> > > > community would like to participate in such an experiment?
> > > >
> > > >
> > > > On Wed, Aug 21, 2013 at 4:34 AM, Alex Lourie <djay.il@xxxxxxxxx> 
> > > > wrote:
> > > > > Albert
> > > > >
> > > > > We don't need to exaggerate. Though TDD is, indeed, a development 
> > > > > methodology, it is not supposed to completely change the way 
> > > > > everyone works.
> > > > >
> > > > > Just consider that writing a good test takes about 10 minutes, 
> > > > > and that each developer writes one or two tests for new stuff 
> > > > > they add (or the old one they fix) from time to time. Then, in 
> > > > > time, you'll have part of your code tested, which is exactly what 
> > > > > we're aiming for. Beginning is hard, continue something is easier.
> > > > >
> > > > > I have never heard a project die because they decided to move to 
> > > > > TDD. And I heard about lots of hits on the matter.
> > > > >
> > > > >
> > > > > On Tue, Aug 20, 2013 at 3:37 AM, Albert Palacios 
> > > > > <optimisme@xxxxxxxxx> wrote:
> > > > > > 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 <weberc2@xxxxxxxxx> 
> > > > > > 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, se e 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
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alex Lourie
> > > >
> > > > --
> > > > 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