elementary-dev-community team mailing list archive

[Dane Henson <dane@xxxxxxxxxxxxxxxx>]

Craig, I had a feeble attempt at it here:
lp:~thegreatdane/+junk/agenda-tests

The tests are uninteresting, but cmake builds the test binary and you can
execute it using make test.
On May 30, 2013 10:53 AM, "Craig" <weberc2@xxxxxxxxx> wrote:

> So I'm liking the look of the GLib Testing environment (see this example:
> https://live.gnome.org/Vala/TestSample)  It seems fairly analogous to
> other testing suites I've used (which probably doesn't mean it's done well,
> but at least it means there is probably a wealth of
> experience/documentation to draw upon--my own included). Unfortunately,
> CMake is the blackest of magics in my mind, so could someone better versed
> in these dark arts help me set up a test project structure that would bring
> in the necessary dependencies and create a test binary? I would like to
> experiment with this, and, if possible, we could implement this in other
> apps and start writing tests.
>
>
> On Mon, May 20, 2013 at 1:53 AM, Pál Dorogi <pal.dorogi@xxxxxxxxx> wrote:
>
>> 1.) Checked, thx.
>> 2.) Yep, that's correct.
>> 3.) Yep, that's nearly same what I have already said (Toolkits are
>> quite stable, and if there is any bug in toolkit we need to get them
>> fixed (or have some workarounds))
>>
>> I just talked about TDD /wo GUI Testing as both of them can be
>> independent from each other, means no any (not really true) dependency
>> between them (TDD is testing using Unit test, BDD is customer/user
>> related acceptance test).
>>
>>
>>
>> On 20 May 2013 14:31, Sergey "Shnatsel" Davidoff
>> <sergey@xxxxxxxxxxxxxxxx> wrote:
>> > 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
>>
>> --
>> 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
>
>