Interesting, I added your repo to the doc if you don't mind :) Met vriendelijke groet,
Jaap Broekhuizen Aquamarijnstraat 273 9743 PG Groningen jaap.broekhuizen.nu [email protected] 06 - 39 81 36 97 On Mon, Apr 29, 2013 at 3:11 PM, Dane Henson <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> >>> 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" < >>> [email protected]> >>> >>> 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" <[email protected]> >>> wrote: >>> >>>>> >>> >>>>> I dunno, I am a newbie here. >>> >>>>> >>> >>>>> On 26 April 2013 22:24, Craig <[email protected]> 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" <[email protected]> >>> 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 <[email protected]> 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 : [email protected] >>> >>>>> >> > Unsubscribe : https://launchpad.net/~elementary-dev-community >>> >>>>> >> > More help : https://help.launchpad.net/ListHelp >>> >>>>> >> > >>> >>>>> >>> >>>>> -- >>> >>>>> Mailing list: https://launchpad.net/~elementary-dev-community >>> >>>>> Post to : [email protected] >>> >>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>> >>>>> More help : https://help.launchpad.net/ListHelp >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Mailing list: https://launchpad.net/~elementary-dev-community >>> >>>> Post to : [email protected] >>> >>>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>> >>>> More help : https://help.launchpad.net/ListHelp >>> >>>> >>> >>> >>> >>> -- >>> >>> Mailing list: https://launchpad.net/~elementary-dev-community >>> >>> Post to : [email protected] >>> >>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>> >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >> >>> >> -- >>> >> Mailing list: https://launchpad.net/~elementary-dev-community >>> >> Post to : [email protected] >>> >> Unsubscribe : https://launchpad.net/~elementary-dev-community >>> >> More help : https://help.launchpad.net/ListHelp >>> >> >>> > >>> > >>> > -- >>> > Mailing list: https://launchpad.net/~elementary-dev-community >>> > Post to : [email protected] >>> > Unsubscribe : https://launchpad.net/~elementary-dev-community >>> > More help : https://help.launchpad.net/ListHelp >>> > >>> >>> -- >>> Mailing list: https://launchpad.net/~elementary-dev-community >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~elementary-dev-community >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> -- >> Mailing list: https://launchpad.net/~elementary-dev-community >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~elementary-dev-community >> More help : https://help.launchpad.net/ListHelp >> >> >
-- Mailing list: https://launchpad.net/~elementary-dev-community Post to : [email protected] Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
