Re: [Elementary-dev-community] Test Driven Development

[Pál Dorogi]

Also, here comes a nice article about Objectum-Oriented Software
Enginering (http://pl.cs.jhu.edu/oose/lectures/design-principles.shtml)
which worth reading (one or two pages) and based on a really good,
would say the best, book I have ever read about the DP (Head First
Design patterns).

On 30 April 2013 06:54, Pál Dorogi  wrote:
> Hi,
>
> The ctest has a lot of parameter as the "make ctest" just gives you a
> simple output. Play a bit /w gtester and ctest either.
>
> I think the main raison is that TDD is forcing the developers to write
> loosely coupled code. Therefore, based on this you will just have
> advantages. You do not need to follow TDD to write unit tests as lot
> of do, but that's nothing to do /w TDD.
> Also, we should have some Mock library either but I do not know how
> could write one in Vala as it need big support of serialization which
> does not really exist in Vala. Also it should have some DI what I have
> already written in my Framework (parametrized constructor injection)
> which works like this (the classes has constructor parameters which
> are resolved either in running time):
>
> var view =  (ContactManagerView) Bootstrapper.get_instance (typeof
> (ContactManagerView));
> ...
>
> container = new CachedContainer ();
> container.register_key (typeof (PersonEditorView));
> container.register_key (typeof (ContactManagerView));
> container.register_key (typeof (PersonEditorPresentation));
>
> You can have a look at some details on  my first post about it
> (http://ilapstech.blogspot.com.au/2013/04/advanced-programming-in-vala-dafs.html).
> Oooh, my framework has a unit test library either. It's based on
> libgee's and some other test classes and it support async tests too.
> Sorry, I did not want to advertise my framework here, I just mentioned
> it because it has those good stuffs which are necessary for TDD.
>
> Read this blog's post
> http://wundasworld.blogspot.com.au/2007/09/good-practices-are-beyond-testing.html
> for starting point about TDD and you can have a bunch of info on the
> Net if you/re interested in it.
>
> Cheers,
>
> ilap
>
>
> On 29 April 2013 21:11, Dane Henson  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.  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  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  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 CMakeLi

Re: [Elementary-dev-community] Test Driven Development

[Pál Dorogi]

Sorry, "make ctest" --> "make test"

On 30 April 2013 06:54, Pál Dorogi  wrote:
> Hi,
>
> The ctest has a lot of parameter as the "make ctest" just gives you a
> simple output. Play a bit /w gtester and ctest either.
>
> I think the main raison is that TDD is forcing the developers to write
> loosely coupled code. Therefore, based on this you will just have
> advantages. You do not need to follow TDD to write unit tests as lot
> of do, but that's nothing to do /w TDD.
> Also, we should have some Mock library either but I do not know how
> could write one in Vala as it need big support of serialization which
> does not really exist in Vala. Also it should have some DI what I have
> already written in my Framework (parametrized constructor injection)
> which works like this (the classes has constructor parameters which
> are resolved either in running time):
>
> var view =  (ContactManagerView) Bootstrapper.get_instance (typeof
> (ContactManagerView));
> ...
>
> container = new CachedContainer ();
> container.register_key (typeof (PersonEditorView));
> container.register_key (typeof (ContactManagerView));
> container.register_key (typeof (PersonEditorPresentation));
>
> You can have a look at some details on  my first post about it
> (http://ilapstech.blogspot.com.au/2013/04/advanced-programming-in-vala-dafs.html).
> Oooh, my framework has a unit test library either. It's based on
> libgee's and some other test classes and it support async tests too.
> Sorry, I did not want to advertise my framework here, I just mentioned
> it because it has those good stuffs which are necessary for TDD.
>
> Read this blog's post
> http://wundasworld.blogspot.com.au/2007/09/good-practices-are-beyond-testing.html
> for starting point about TDD and you can have a bunch of info on the
> Net if you/re interested in it.
>
> Cheers,
>
> ilap
>
>
> On 29 April 2013 21:11, Dane Henson  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.  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  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  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)

Re: [Elementary-dev-community] Test Driven Development

[Pál Dorogi]

Hi,

The ctest has a lot of parameter as the "make ctest" just gives you a
simple output. Play a bit /w gtester and ctest either.

I think the main raison is that TDD is forcing the developers to write
loosely coupled code. Therefore, based on this you will just have
advantages. You do not need to follow TDD to write unit tests as lot
of do, but that's nothing to do /w TDD.
Also, we should have some Mock library either but I do not know how
could write one in Vala as it need big support of serialization which
does not really exist in Vala. Also it should have some DI what I have
already written in my Framework (parametrized constructor injection)
which works like this (the classes has constructor parameters which
are resolved either in running time):

var view =  (ContactManagerView) Bootstrapper.get_instance (typeof
(ContactManagerView));
...

container = new CachedContainer ();
container.register_key (typeof (PersonEditorView));
container.register_key (typeof (ContactManagerView));
container.register_key (typeof (PersonEditorPresentation));

You can have a look at some details on  my first post about it
(http://ilapstech.blogspot.com.au/2013/04/advanced-programming-in-vala-dafs.html).
Oooh, my framework has a unit test library either. It's based on
libgee's and some other test classes and it support async tests too.
Sorry, I did not want to advertise my framework here, I just mentioned
it because it has those good stuffs which are necessary for TDD.

Read this blog's post
http://wundasworld.blogspot.com.au/2007/09/good-practices-are-beyond-testing.html
for starting point about TDD and you can have a bunch of info on the
Net if you/re interested in it.

Cheers,

ilap


On 29 April 2013 21:11, Dane Henson  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.  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  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  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)
>>>
>>>
>>> ###

Re: [Elementary-dev-community] Test Driven Development

[Dane Henson]

At this point, that might be the best course of action. They always say
it's not about the framework, it's about whether or not you test. Maybe
with more better informed developers, we will have a few tried and true
methods in a few cycles that we can use as teaching tools.

I would love to read your take on TDD regardless. It might give us better
direction.
On Apr 29, 2013 3:48 PM, "Craig"  wrote:

> Given the novelty of TDD to many of elementary's developers, I think it
> might be useful to decouple TDD concepts from any particular framework.
> With that in mind, I think we should consider teaching TDD fundamentals
> with either no framework or one that has an insignificant learning curve.
> I'm considering writing a blog post introducing TDD in this way. Thoughts?
> On Apr 29, 2013 8:26 AM, "Jaap Broekhuizen"  wrote:
>
>> 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
>> jaap...@gmail.com
>> 06 - 39 81 36 97
>>
>>
>> On Mon, Apr 29, 2013 at 3:11 PM, Dane Henson 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.
>>>  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 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 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 (Ext

Re: [Elementary-dev-community] Test Driven Development

[Craig]

Given the novelty of TDD to many of elementary's developers, I think it
might be useful to decouple TDD concepts from any particular framework.
With that in mind, I think we should consider teaching TDD fundamentals
with either no framework or one that has an insignificant learning curve.
I'm considering writing a blog post introducing TDD in this way. Thoughts?
On Apr 29, 2013 8:26 AM, "Jaap Broekhuizen"  wrote:

> 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
> jaap...@gmail.com
> 06 - 39 81 36 97
>
>
> On Mon, Apr 29, 2013 at 3:11 PM, Dane Henson 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.
>>  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 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 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
>

Re: [Elementary-dev-community] Test Driven Development

[Jaap Broekhuizen]

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
jaap...@gmail.com
06 - 39 81 36 97


On Mon, Apr 29, 2013 at 3:11 PM, Dane Henson  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.
>  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 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  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
>>>

Re: [Elementary-dev-community] Test Driven Development

[Dane Henson]

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.
 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  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  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}$

Re: [Elementary-dev-community] Test Driven Development

[Jaap Broekhuizen]

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  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  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