elementary-dev-community team mailing list archive

["Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx>]

1) We have quite a few behavioral testing frameworks (see the doc or
pitti's session)
2) BDD is language-independent, it only cares about the toolkit
3) We haven't yet run into any toolkit bugs AFAIK, but when we do, we'd
have to get them fixed all the same.


2013/5/20 Pál Dorogi <pal.dorogi@xxxxxxxxx>

> Yep, you are right, we need both. but we currently do not have any GUI
> Testing framework /w Vala. Also, I meant by "we do not need any GUI
> test which is very hard to achieve" that  we do not need  to have any
> GUI Test to start applying TDD and if there is any bug in the toolkit
> which would affect the app then we cannot do much about that.
>
> On 19 May 2013 22:34, Jaap Broekhuizen <jaapz.b@xxxxxxxxx> wrote:
> >> So, using OOP (and the other things I talked about) we can separate
> > the GUI code from the Business Logic (loose coupling and others),
> > therefore we do not need any GUI Test which is very hard to achieve.
> > Also, I would say the Toolkits are quite stable and have some strict
> > APIs, but if there is a bug in any Toolkit, we cannot do much but wait
> > for their fix.
> >
> > I don't agree. GUI/Behavioral testing is not meant to unittest the GUI
> > framework, it is to test whether the GUI is behaving after the
> > specification. You are basically testing the User Experience
> automatically
> > (not completely true, but close enough).
> >
> > We will need Unit Testing and Behavioral Testing both.
> >
> > Met vriendelijke groet,
> >
> > Jaap Broekhuizen
> >
> > Aquamarijnstraat 273
> > 9743 PG  Groningen
> >
> > jaap.broekhuizen.nu
> > jaapz.b@xxxxxxxxx
> > 06 - 39 81 36 97
> >
> >
> > On Sun, May 19, 2013 at 3:26 PM, Pál Dorogi <pal.dorogi@xxxxxxxxx>
> wrote:
> >>
> >> I have read it, but, it's not really what I talked about. The facts,
> >> that we need nice GUI Apps in eOS which should be written in Vala.
> >> Vala is a real OOP language therefore we could use it writing apps
> >> using OOP principles and can forget all the old fashioned programming
> >> in C things which is still very common (I grew up /w C, loved and
> >> still love it, but not for GUI apps) in Linux GUI programming.
> >>
> >> So, using OOP (and the other things I talked about) we can separate
> >> the GUI code from the Business Logic (loose coupling and others),
> >> therefore we do not need any GUI Test which is very hard to achieve.
> >> Also, I would say the Toolkits are quite stable and have some strict
> >> APIs, but if there is a bug in any Toolkit, we cannot do much but wait
> >> for their fix.
> >> So, we can focus on the stability of the App as we do not need to
> >> really care about the GUI as it can live without our layers.
> >>
> >> Also, the bugs, for example, if we do not use OOP principles and if
> >> there is a bug in an app, it could affect all the code base if it's
> >> not well structured (lot of "hard" cross dependencies to the other
> >> Objects, for example lot of "using" in the source codes where we
> >> should not use that/those module(s)/object(s) at all and some other
> >> smell-code things. And a bit later an other bug appears, and an other,
> >> and one more.
> >> So, how would we fix it? How could we work on it parallel if my
> >> work/fix would affect to the whole app?
> >> It would be a real mess in solving the issue as a lot of cross
> >> dependencies are across all the code base. In my experience it would
> >> be a nightmare. With TDD we can use tests for the trivial bug hunting
> >> and also we can create a test method(s) for the newly appeared bugs
> >> and we could fix them more easily than in the current development
> >> cycles, of course if we structured the app to handle these situations.
> >>
> >> But, keep in mind these things I talked about (TDD, Design Patterns,
> >> SOLID etc.)  are not the Holy Grail for everything, but some helpers
> >> which can make our life much easier if we fully understand and are
> >> able to implement them, which could be as everything can be found in
> >> the Internet and we have a nice programming language: Vala which is
> >> capable for implement those things.
> >>
> >>
> >>
> >> On 19 May 2013 19:56, Sergey "Shnatsel" Davidoff
> >> <sergey@xxxxxxxxxxxxxxxx> wrote:
> >> > To everyone interested in implementing automated testing and QA
> >> > procedures I
> >> > highly recommend reading logs Martin Pitt's Ubuntu Dev Week sessions
> on
> >> > the
> >> > topic. They can be found at
> >> > http://irclogs.ubuntu.com/2013/01/31/%23ubuntu-classroom.html, his
> IRC
> >> > nick
> >> > is "pitti".
> >> >
> >> > I've added some things he mentioned to our document
> >> >
> >> > (
> https://docs.google.com/document/d/1cTsWpeT0h4FD81T-xs4bEWlALsO__j3rL1A7iB-SWz0/edit
> ),
> >> > especially on behavioral testing, but I still highly recommend reading
> >> > the
> >> > original session.
> >> >
> >> >
> >> > 2013/4/29 Jaap Broekhuizen <jaapz.b@xxxxxxxxx>
> >> >>
> >> >> Pal, that looks very interesting, please do upload it to launchpad so
> >> >> we
> >> >> can have a closer look :)
> >> >>
> >> >> In te mean time, I have created a google document to have a central
> >> >> point
> >> >> of investigation for elementary automated testing. Feel free to add
> >> >> information to the doc whenever you can, but please keep it clean! :)
> >> >> You
> >> >> can find it here:
> >> >>
> >> >>
> https://docs.google.com/document/d/1cTsWpeT0h4FD81T-xs4bEWlALsO__j3rL1A7iB-SWz0/edit
> >> >>
> >> >> I haven't found any BDD frameworks yet, but I have found some
> >> >> interesting
> >> >> testing frameworks.
> >> >>
> >> >> I think I'll set up a testing branch for granite some day later this
> >> >> week,
> >> >> maybe test out the different frameworks so we can see what suits us
> >> >> best. If
> >> >> anyone else wants to start setting up a branch like that, you are of
> >> >> course
> >> >> free to do so ;)
> >> >>
> >> >> --
> >> >> Jaap
> >> >>
> >> >> On Mon, Apr 29, 2013 at 3:08 AM, Pál Dorogi <pal.dorogi@xxxxxxxxx>
> >> >> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> You can use cmake for unit test as it supports GLib's test. I use
> >> >>> MonoDevelop/Xamarin Studio for developing for huge projects coexists
> >> >>> /w cmake (as MD/XS does not support cmake). MD is for rapid
> >> >>> development but there is no internal Unit to support vala but C#
> >> >>> (Nunit) and some other languages. So, I run some cmake command
> before
> >> >>> and after MD build which runs cmake for cmake build and run test.
> For
> >> >>> example:
> >> >>>
> >> >>> before build: cmake .. in /build/ dir
> >> >>> after build in MD: run build/test/unit_test
> >> >>>
> >> >>> I added CMakeLists.txt into my MD project and I just need to sync
> >> >>> betwwen MD and that file when I add or remove a Vala source file
> >> >>> into/from the MD.
> >> >>>
> >> >>> I do not know how would it works /w launchpad as I do not know how
> its
> >> >>> packaging works /w cmake's unit test, but I think it should work.
> >> >>> You just need add some stanza in the project's root CMakeList.txt
> like
> >> >>> this, but it's not simpe as it's using some other features like
> >> >>> external projects and so on.
> >> >>> set (PROJECT_TEST tests)
> >> >>>
> >> >>> ...
> >> >>> enable_testing (true)
> >> >>> add_subdirectory (${PROJECT_TEST})
> >> >>>
> >> >>> and add create some CMakeList.txt in the ./test dir
> >> >>>
> >> >>>
> >> >>>
> ###############################################################################
> >> >>> # Sources
> >> >>>
> >> >>>
> >> >>>
> ###############################################################################
> >> >>> set (UNIT_TESTS unit_tests)
> >> >>>
> >> >>> set (VALA_SOURCES
> >> >>> Model/Address.vala
> >> >>> Model/Person.vala
> >> >>> Model/Gender.vala
> >> >>> ValidatorTest.vala
> >> >>>     TestMain.vala
> >> >>> )
> >> >>>
> >> >>> set (PKG_DEPS gtk+-3.0 glib-2.0 gee-1.0)
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> ################################################################################
> >> >>> # set (CMAKE_VERBOSE_MAKEFILE ON)
> >> >>> set (CMAKE_FIND_LIBRARY_SUFFIXES .so)
> >> >>>
> >> >>> # External Packages definitions.
> >> >>> set (EXTERN_PROJ dafunit)
> >> >>> set (EXTERN_SOURCE_DIR src)
> >> >>>
> >> >>> set (INTERN_PROJ dafvalidation)
> >> >>> set (INTERN_SOURCE_DIR ${PROJECT_SOURCE})
> >> >>>
> >> >>> include (ExternalProject)
> >> >>>
> >> >>> ExternalProject_Add (${EXTERN_PROJ}
> >> >>>     #PREFIX ../../${EXTERN_PROJ}
> >> >>>     SOURCE_DIR ../../../${EXTERN_PROJ}
> >> >>>     BINARY_DIR ${CMAKE_BINARY_DIR}/${EXTERN_PROJ}/build
> >> >>>     INSTALL_DIR ""
> >> >>>     UPDATE_COMMAND ""
> >> >>>     PATCH_COMMAND ""
> >> >>>     INSTALL_COMMAND ""
> >> >>> )
> >> >>>
> >> >>> ExternalProject_Get_Property(${EXTERN_PROJ} BINARY_DIR)
> >> >>> include_directories (${BINARY_DIR}/${EXTERN_SOURCE_DIR})
> >> >>> include_directories (${CMAKE_BINARY_DIR}/${INTERN_SOURCE_DIR})
> >> >>>
> >> >>> # PkgConfig
> >> >>> find_package (PkgConfig)
> >> >>> find_package (GObjectIntrospection 0.9.12)
> >> >>> include (GObjectIntrospectionMacros)
> >> >>>
> >> >>> pkg_check_modules(DEPS REQUIRED ${PKG_DEPS})
> >> >>>
> >> >>> set (CFLAGS ${DEPS_CFLAGS} ${DEPS_CFLAGS_OTHER})
> >> >>> add_definitions (${CFLAGS})
> >> >>> set (LIBS ${DEPS_LIBRARIES})
> >> >>> set(LIB_PATHS ${DEPS_LIBRARY_DIRS})
> >> >>> link_directories(${LIB_PATHS})
> >> >>>
> >> >>> # Does not work set (ENV{PKG_CONFIG_PATH}
> ${EXTERNAL_BINARY_DIR}/src)
> >> >>> vala_precompile (VALA_C
> >> >>> ${VALA_SOURCES}
> >> >>> PACKAGES
> >> >>> ${PKG_DEPS}
> >> >>>     posix
> >> >>> CUSTOM_VAPIS
> >> >>>     ${CMAKE_BINARY_DIR}/${INTERN_SOURCE_DIR}/${INTERN_PROJ}.vapi
> >> >>> ${BINARY_DIR}/${EXTERN_SOURCE_DIR}/${EXTERN_PROJ}.vapi
> >> >>> OPTIONS
> >> >>> )
> >> >>>
> >> >>> add_executable (${UNIT_TESTS} ${VALA_C})
> >> >>>
> >> >>> # Does not work add_dependencies (unit_tests dafvalidation)
> >> >>>
> >> >>> target_link_libraries(${UNIT_TESTS} ${LIBS})
> >> >>> target_link_libraries(${UNIT_TESTS}
> >> >>>
> >> >>>
> >> >>>
> ${BINARY_DIR}/${EXTERN_SOURCE_DIR}/${CMAKE_FIND_LIBRARY_PREFIXES}${EXTERN_PROJ}${CMAKE_FIND_LIBRARY_SUFFIXES})
> >> >>> target_link_libraries(${UNIT_TESTS}
> >> >>>
> >> >>>
> >> >>>
> ${CMAKE_BINARY_DIR}/${INTERN_SOURCE_DIR}/${CMAKE_FIND_LIBRARY_PREFIXES}${INTERN_PROJ}${CMAKE_FIND_LIBRARY_SUFFIXES})
> >> >>> add_test(${UNIT_TESTS} ${CMAKE_CURRENT_BINARY_DIR}/${UNIT_TESTS})
> >> >>> ###################################################
> >> >>>
> >> >>>
> >> >>> I am going to upload it to lp so, if you would like to have a look
> at
> >> >>> it just let me know and that case I will uploadid it on some day in
> >> >>> this week
> >> >>>
> >> >>> On 29 April 2013 07:19, Lochlan Bunn <loklaan@xxxxxxxxx> wrote:
> >> >>> > I have read alot about TTD, both in school and in persistent
> >> >>> > articles.
> >> >>> > I've
> >> >>> > used it to develop a small gui based game, and I can say that I
> >> >>> > liked
> >> >>> > the
> >> >>> > flow once I was used to it. I used JUnit & Eclipse, and that was
> all
> >> >>> > that
> >> >>> > was needed the whole time.
> >> >>> >
> >> >>> > So when it comes to elementary dev, and vala/gtk/linux dev in
> >> >>> > general,
> >> >>> > I'd
> >> >>> > be interested in reading/learning how to write unit test (suites)
> >> >>> > for
> >> >>> > vala
> >> >>> > in respects to both CI, a la Launchpad, packaging, and moreso in
> an
> >> >>> > IDE.
> >> >>> >
> >> >>> >
> >> >>> > On 27 April 2013 07:48, Craig <weberc2@xxxxxxxxx> wrote:
> >> >>> >>
> >> >>> >> 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
> >> >>> >>>
> >> >>> >>
> >> >>> >> --
> >> >>> >> 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
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Sergey "Shnatsel" Davidoff
> >> > OS architect @ elementary
> >
> >
>



-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary