elementary-dev-community team mailing list archive

[Craig <weberc2@xxxxxxxxx>]

I agree wholeheartedly. And as Cassidy mentioned, we can use scratch as the
incubation project.  Would any devs be interested in volunteering to learn?
Jaap, would you be interested in helping instruct?
On Apr 26, 2013 3:25 PM, "Jaap Broekhuizen" <jaapz.b@xxxxxxxxx> wrote:

> I also think implementing Behavorial testing (applying BDD) is very
> relevant for us, as we are focussing a lot on user interface and
> interaction.
>
> So imo we should start on a project which we can use as a playground for
> both unit an behavorial testing.
>
> Does anyone know of good vala bdd frameworks?
>
> Jaap
> Op 26 apr. 2013 22:21 schreef "Cassidy James" <cassidy@xxxxxxxxxxxxxxxx>
> het volgende:
>
>> I don't think we need any convincing; everything I've heard from the devs
>> is that we need to do this. It's just a matter of figuring out a common way
>> of doing it.
>>
>> Craig, a relatively small/new project that could use testing is the new
>> Scratch or even the new work going on with Contractor. Both are (from what
>> I understand) fresh codebases and now might be the time to work  on tests.
>> I recommend you hop into #elementary-dev and work with the devs on getting
>> some tests worked out.
>>
>> Regards,
>> Cassidy
>> On Apr 26, 2013 11:04 AM, "Pál Dorogi" <pal.dorogi@xxxxxxxxx> wrote:
>>
>>> I dunno, I am a newbie here.
>>>
>>> On 26 April 2013 22:24, Craig <weberc2@xxxxxxxxx> wrote:
>>> > That's exactly what I'd like to know: how can I help. I can try and
>>> post
>>> > some tutorials, but I'd like to know who is interested and what the
>>> > development community already knows.
>>> >
>>> > On Apr 26, 2013 6:39 AM, "Pál Dorogi" <pal.dorogi@xxxxxxxxx> wrote:
>>> >>
>>> >> Hi Craig,
>>> >>
>>> >> I agree 100% /w you, but I think you should write some tutorials and
>>> >> post them in your blog, if you have any. But in my opinion that the
>>> >> human beings do not like "re-learn" things and the real OOP, Design
>>> >> Patterns, SOLID, TDD etc. etc. are very steep and time for a non-real
>>> >> OOP/DP experienced Programmer/Developer.
>>> >> Also, the learning curve is very steep for these advanced stuffs and
>>> >> needs long time to get there. But, nobody would not know how good are
>>> >> they until haven't learnt and used those stuffs, would they?.:)
>>> >>
>>> >> I did sine similar things, getting some new fresh things (TDD,
>>> >> MvvM/Presentation Model Design Pattern) to programming in Vala
>>> >>
>>> >> ((
>>> http://ilapstech.blogspot.com/2013/04/advanced-programming-in-vala-dafs.html
>>> )
>>> >> but you should keep in mind that this kind of new things (TDD, DP,
>>> >> SOLDI, MVVM etc. etc.) are like evolution (evolution in Programming)
>>> >> which needs some time to get it succeeded (or failed).:)
>>> >>
>>> >> On 26 April 2013 20:36, Craig <weberc2@xxxxxxxxx> wrote:
>>> >> > Hello everyone,
>>> >> >
>>> >> > I'm just leaving San Jose after having spent a week listening to a
>>> lot
>>> >> > of
>>> >> > smart people talk about, among other things, Test Driven Development
>>> >> > (TDD).
>>> >> > I know I keep harping on this, but among the people who write the
>>> >> > coolest,
>>> >> > best software (and other average software folks) TDD is seen as
>>> >> > absolutely
>>> >> > critical. I can't point to anything other discipline in the software
>>> >> > world
>>> >> > that is of comparable importance. And here's why:
>>> >> >
>>> >> > When we start writing software, we can manage it with a couple of
>>> >> > developers, perhaps all the way up through the first release;
>>> however,
>>> >> > as we
>>> >> > add features, our software becomes more complex. It's hard for us to
>>> >> > remember what parts of our programs worked well before and what
>>> parts
>>> >> > are
>>> >> > broken. We often make changes to the underlying architecture to
>>> >> > facilitate a
>>> >> > new feature, but we're not exactly sure if in doing so, we broke an
>>> >> > existing
>>> >> > feature. And we'll of course do a little ad hoc manual testing to
>>> verify
>>> >> > that things still work, but we're only going to really check 5-10%
>>> of
>>> >> > the
>>> >> > code that we most suspect would break. And even if we do power
>>> through,
>>> >> > we're only going to ever check 60-70% of the code, and it's all a
>>> very
>>> >> > slow,
>>> >> > unreliable process. Soon we spend all of our time fighting bugs and
>>> we
>>> >> > can
>>> >> > never get around to any interesting work. Does this pattern sound
>>> >> > familiar?
>>> >> >
>>> >> > With TDD, you write a simple, small test for every piece of
>>> interesting
>>> >> > code
>>> >> > you write, and every time you rebuild the project, all of your old
>>> tests
>>> >> > run. If you're writing good tests, you can be assured that all of
>>> your
>>> >> > code
>>> >> > works as you intend it to every single time you build, and if
>>> someone
>>> >> > merges
>>> >> > in a bug, it will be caught immediately (and the test that fails
>>> will
>>> >> > give
>>> >> > you some good information about what broke/where the bug is hiding).
>>> >> >
>>> >> > Of course, it takes time to write tests; however, it's still much
>>> less
>>> >> > time
>>> >> > than you would spend debugging your code. Furthermore, when you
>>> write
>>> >> > tests
>>> >> > before you write your production code, you are forced to design your
>>> >> > code
>>> >> > modularly just to make it testable. Among software professionals,
>>> TDD is
>>> >> > seen as the fastest way to write software. I mean, Luna has been 90%
>>> >> > complete for 90% of its development cycle, and this is a common
>>> pattern
>>> >> > in
>>> >> > the software world.
>>> >> >
>>> >> > With all of this in mind, I'd like to know how I can help you guys
>>> start
>>> >> > practicing TDD? If this hasn't persuaded you, I'd appreciate it if
>>> you
>>> >> > would
>>> >> > respond and give your perspective so we can talk about it. I'm very
>>> >> > interested in seeing you guys continue to put out great software,
>>> but
>>> >> > I'm
>>> >> > concerned that as you write more code, you're going to be creating
>>> more
>>> >> > for
>>> >> > yourselves to maintain and the amount of time you spend writing new
>>> >> > software
>>> >> > is going to drop off exponentially as the complexity (as complexity
>>> >> > produces
>>> >> > bugs) increases.
>>> >> >
>>> >> > Please let me know if/how I can help you.
>>> >> >
>>> >> > Craig
>>> >> >
>>> >> > --
>>> >> > 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
>
>