← Back to team overview

elementary-dev-community team mailing list archive

Re: Test Driven Development

 

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
>

Follow ups

References