I'm game. It's pretty easy to use Hangouts on Air, but I can help out if needed.
Regards, Cassidy James -- Sent from *elementary OS* <http://elementaryos.org/>. On Tue, Jun 25, 2013 at 9:51 PM, Craig <webe...@gmail.com> wrote: > This is much-delayed, but would you mind doing a code-walk hangout > sometime, demonstrating how this whole test thing works? Could you go > through a live example of writing a simple app and the tests for it, as > well as how to execute the test? If that sounds too involved, I would be > happy with anything. Anyone who wanted to participate could, and we could > also record it to YouTube to share with other devs. Cassidy James can teach > us how to set up all the youtube recording and whatnot if you don't know > how? > > Would you have the time to do something like this? > > > On Mon, Apr 29, 2013 at 8:11 AM, Dane Henson <d...@elementaryos.org>wrote: > >> Thanks for setting up that document. I've already added a few things and >> commented a bit. I have been toying with GTest (GLib.Test) a bit, but >> haven't been substantially impressed by it yet. You can see my noodling >> with it at >> lp:~thegreatdane/+junk/agenda-tests<https://code.launchpad.net/~thegreatdane/+junk/agenda-tests>. >> It's not much, but it might give someone an idea of how to set up cmake >> for this sort of thing. That's what took me the longest and it's probably >> still wrong, but it works :P. >> >> The code being tested is trivial, just something to play with based on an >> idea I had for agenda, so don't be overly critical please. >> >> mkdir build; cd build >> cmake .. >> make >> make test >> >> >> >> On Mon, Apr 29, 2013 at 3:26 AM, Jaap Broekhuizen <jaap...@gmail.com>wrote: >> >>> 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 >>> >>> >> >> -- >> 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