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 <ser...@elementaryos.org> 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.dor...@gmail.com> >> >> 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 <jaap...@gmail.com> 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 >> > jaap...@gmail.com >> > 06 - 39 81 36 97 >> > >> > >> > On Sun, May 19, 2013 at 3:26 PM, Pál Dorogi <pal.dor...@gmail.com> >> > 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 >> >> <ser...@elementaryos.org> 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 <jaap...@gmail.com> >> >> >> >> >> >> 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.dor...@gmail.com> >> >> >> 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 <lokl...@gmail.com> 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 <webe...@gmail.com> 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" <jaap...@gmail.com> >> >> >>> >> 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" >> >> >>> >>> <cass...@elementaryos.org> >> >> >>> >>> 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.dor...@gmail.com> >> >> >>> >>>> wrote: >> >> >>> >>>>> >> >> >>> >>>>> I dunno, I am a newbie here. >> >> >>> >>>>> >> >> >>> >>>>> On 26 April 2013 22:24, Craig <webe...@gmail.com> 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.dor...@gmail.com> >> >> >>> >>>>> > 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 <webe...@gmail.com> 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@lists.launchpad.net >> >> >>> >>>>> >> > 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@lists.launchpad.net >> >> >>> >>>>> 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@lists.launchpad.net >> >> >>> >>>> 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@lists.launchpad.net >> >> >>> >>> 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@lists.launchpad.net >> >> >>> >> 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@lists.launchpad.net >> >> >>> > 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@lists.launchpad.net >> >> >>> 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@lists.launchpad.net >> >> >> 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp