subject:"\[Vala\] Using TestCase class\: assert \(this is Object\) fails in method, but not in constructor"

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-05 Thread Felipe Lavratti

This is a nice pull request even, I've merged it.

Is there a simple way to automatically detect and fill the tests lists?

Also, what extra features would be nice to see in this template ?

Thanks!

On Fri, Feb 5, 2016 at 3:44 AM, Evan Nemerson  wrote:
> You're missing support for `make test`.
>
> This is a bit more complicated than it needs to be since recent
> versions of CMake will complain if you try to create a "test" target;
> they've decided to reserve it for their ctest framework, so the only
> real choice is to use ctest.
>
> ctest is really geared towards executing multiple small test programs
> instead of one monolithic test, but you can get around that by running
> the same executable multiple times and having and only executing a
> subset of the tests each time.  If you don't, the ctest output will
> always treat your tests as a single test, and the usefulness of reports
> will be quite limited.
>
> If you want an example, you can look at
> ; it
> is for C tests using µnit not Vala tests using glib, but that only
> makes a difference in how you build the executable… the ctest
> integration part is the same.
>
> Assuming your executable is `my_project_unit_tests', you would want
> something like this:
>
> # Enable ctest
> enable_testing()
>
> # Build your executable here, you'll have to figure this part out
> # on your own, it's project-specific.
> add_executable(my_project_unit_tests …)
>
> # List of tests in the `my_project_unit_tests' executable that you
> # want to execute.  The project currently only has a single test,
> # "/my_class/foo", so I've added a few more so you get the idea.
> set(MY_PROJECT_TESTS
>   /my_class/foo
>   /my_class/bar
>   /my_class/baz
>   /your_class)
>
> foreach(test_name ${MY_PROJECT_TESTS})
>   add_test(NAME ${test_name}
> COMMAND $ -p ${test_name})
> endforeach(test_name)
>
> The only line here that really needs an explanation is the second to
> last.  The $<…> thing is a generator expression; see  /cmake/help/v3.0/manual/cmake-generator-
> expressions.7.html#manual:cmake-generator-expressions%287%29>.  In that
> case it will just be the path to the my_project_unit_tests executable.
>  The `-p ${test_name}' part just tells the executable to execute only a
> specific test instead of all of them.
>
> Once you're done, you should be able to run the tests with either `make
> test` or by just running `ctest` directly.
>
> 
> Also, instead of the build.sh script, I'd like to suggest
> .
> 
>
>
> -Evan
>
>
>
> On Fri, 2016-02-05 at 01:31 -0200, Felipe Lavratti wrote:
>> Steven,
>>
>> Since you brought it, I took the liberty to commit a project template
>> with my current setup of using Atom + Vala + Gee TestCase +
>> Cmake.
>>
>> It is here: https://github.com/felipe-lavratti/vala-unittests-cmake
>>
>> Hope it helps.
>>
>>
>> On Thu, Feb 4, 2016 at 9:09 PM, Steven Oliver > m> wrote:
>> > I'm in the process of implementing the gee test suite into my
>> > project. So far so good. The test suite was easy to figure out. So
>> > far my biggest problem has been trying to figure out how to setup
>> > CMake for it all to work.
>> >
>> > Thank you,
>> > Steven N. Oliver
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Feb 4, 2016 at 3:07 PM -0800, "Chris Daley" > > il.com> wrote:
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > You may also find the Gee.TestCase class suits your needs - it
>> > certainly
>> > makes the tests easier to read and is more xUnit like in its
>> > approach than
>> > the 'naked' GLib Test classes.
>> >
>> > https://esite.ch/2012/06/writing-tests-for-vala/
>> >
>> > Gives a good overview - and if I recall the GXml tests that Daniel
>> > mentioned uses it as well.
>> >
>> > Cheers
>> > Chris D
>> >
>> > 2016-02-04 14:09 GMT-08:00 Daniel Espinosa :
>> >
>> > > GXml have a test suite may you want to check. I has more than 50
>> > > tests
>> > > cases.
>> > > El feb. 4, 2016 3:04 PM, "Al Thomas"  escribió:
>> > >
>> > > >
>> > > >
>> > > > - Original Message -
>> > > > > From: Felipe Lavratti
>> > > > > Sent: Thursday, 4 February 2016, 20:18
>> > > > > Subject: [Vala] Using TestCase class: assert (this is Object)
>> > > > > fails in
>> > > > method, but not in constructor
>> > > > >
>> > > > > Have a look at this code:
>> > > > >
>> > > > > public class Tests : Object {
>> > > > >
>> > > > > public Tests () {
>> > > > > assert (this is Object); // THIS ASSERTION PASSES
>> > > > > ts = new TestSuite ("dot_cap_dimmer") ;
>> > > > > ts.add (new TestCase ("construction",
>> > > > > (TestFixtureFunc)
>> > > > > setup, (TestFixtureFunc) test_construction, (TestFixtureFunc)
>> > > > > teardown)) ;
>> > > > > TestSuite.get_root

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-05 Thread Evan Nemerson

Please don't do that.  If you want to force a Perl dependency for your
own project that's fine, but for a template project it's a bad idea.
People using the template will probably be unable to build on Windows.

Also, keep in mind that sometimes test names will be automatically
generated.  For example, GLib doesn't support parameterized tests, so
before I switched Squash to use µnit I would generate a version of each
test for each codec, so for my "/foo/bar" test I would end up with
"/foo/bar/gzip", "/foo/bar/xz", "/foo/bar/brotli", etc. (I think I'm at
about 45 codecs in Squash).  I sincerely doubt your Perl script can
handle that, but it would be easy to do it with what I had.  Even if
you didn't have a way to enumerate the parameter values (the codec, in
this example), you could just have a single "/foo/bar" entry (the -p
option should match all tests in that path, not only a test with that
exact name).



On Fri, 2016-02-05 at 18:57 +, Felipe Lavratti wrote:
> These are nice suggestion Evan! I'll implement some of them in my
> main
> project and then copy it to the template on the go, thank you vm!
> 
> BTW, I just wrote a perl script the find test names in the .vala
> files and
> added to the template project.
> 
> On Fri, Feb 5, 2016 at 4:51 PM Evan Nemerson 
> wrote:
> 
> > On Fri, 2016-02-05 at 13:34 -0200, Felipe Lavratti wrote:
> > > This is a nice pull request even, I've merged it.
> > > 
> > > Is there a simple way to automatically detect and fill the tests
> > > lists?
> > 
> > I don't think so.  CMake requires knowledge of the test names at
> > configure time, so even if you could somehow query the test program
> > for
> > a list of available tests, it would be too late.
> > 
> > If you were using autotools it would be pretty straightforward, at
> > least if you're willing to add a bit of code to your test
> > executable to
> > add an option to enumerate tests (which wouldn't be
> > difficult).  Just
> > have your test target be something like:
> > 
> > for test in $(test-executable --list-tests); do
> >   $(test-executable -p "${test}")
> > done
> > 
> > With cmake, trying to do something similar will not work because
> > they
> > pretty much force you to use ctest.
> > 
> > > Also, what extra features would be nice to see in this template ?
> > 
> > Some things which come to mind based on a very quick look:
> > 
> >  * Since you're using uncrustify anyways, you should add a pre-
> > commit
> >    hook to run it and verify that the code meets the formatting
> >    guidelines you've set.
> >  * Add valadoc support, at least to the library portion of the
> > project.
> > 
> >  * Add a COPYING or LICENSE file (even if it's just a placeholder
> > that
> >    tells people to paste their license).
> >  * Change the name of readme.md to README.md.
> >  * Get rid of build.sh and clean.sh.  They're non-standard and
> > build in
> >    a weird directory.
> >  * Add support for continuous integration.  Travis CI or drone.io
> > are
> >    good, and maybe AppVeyor if you can figure it out (Windows makes
> >    *everything* harder).  Every project should be using CI these
> > days.
> >  * Use GNUInstallDirs.  For projects indented to place nice on non-
> >    Windows platforms it makes things a lot easier.
> >  * I know this is going to seem self-serving because I wrote it,
> > but
> >    use configure-cmake.  It helps make cmake's terrible syntax for
> >    providing arguments much less unpleasant, and helps make
> > projects
> >    more friendly for people used to autotools.
> >  * Disable GCC warnings which are very commonly triggered by
> > correct
> >    Vala code, starting with -Wincompatible-pointer-types.  For this
> >    you'll need to detect which flags the compiler supports; I use
> >  >    s://github.com/quixdb/squash/blob/master/cmake/AddCompilerFlags.
> > cmak
> >    e>, but that may be overkill for you (I have to deal with C++,
> >    adding additional warning flags, compiler-specific flags, etc.)
> >  * Use add_subdirectory() and a CMakeLists.txt in each subdirectory
> >    instead of a single CMakeLists.txt at the top level; it's much
> >    easier as your project gets larger, and CMake doesn't have the
> > same
> >    problems autotools does when you do it.
> >  * Add a .gitignore.
> >  * Add semantic versioning info to the project, use it to set the
> >    VERSION and SOVERSION properties of the library.
> >  * Write the version information to a config.h, add a config.vapi
> > to
> >    bind it, then use it in the exectuable to have --version output
> > the
> >    version.  You may want to also add functions to the library to
> > get
> >    the library version and include both the library and executable
> >    versions in the output of --version
> >  * Use the option parser built in to glib to parse options and
> > handle
> >    the --help argument.
> >  * Install the executable, library, and public headers.  Don't
> > forget
> >    about the

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-05 Thread Felipe Lavratti

These are nice suggestion Evan! I'll implement some of them in my main
project and then copy it to the template on the go, thank you vm!

BTW, I just wrote a perl script the find test names in the .vala files and
added to the template project.

On Fri, Feb 5, 2016 at 4:51 PM Evan Nemerson  wrote:

> On Fri, 2016-02-05 at 13:34 -0200, Felipe Lavratti wrote:
> > This is a nice pull request even, I've merged it.
> >
> > Is there a simple way to automatically detect and fill the tests
> > lists?
>
> I don't think so.  CMake requires knowledge of the test names at
> configure time, so even if you could somehow query the test program for
> a list of available tests, it would be too late.
>
> If you were using autotools it would be pretty straightforward, at
> least if you're willing to add a bit of code to your test executable to
> add an option to enumerate tests (which wouldn't be difficult).  Just
> have your test target be something like:
>
> for test in $(test-executable --list-tests); do
>   $(test-executable -p "${test}")
> done
>
> With cmake, trying to do something similar will not work because they
> pretty much force you to use ctest.
>
> > Also, what extra features would be nice to see in this template ?
>
> Some things which come to mind based on a very quick look:
>
>  * Since you're using uncrustify anyways, you should add a pre-commit
>hook to run it and verify that the code meets the formatting
>guidelines you've set.
>  * Add valadoc support, at least to the library portion of the project.
>
>  * Add a COPYING or LICENSE file (even if it's just a placeholder that
>tells people to paste their license).
>  * Change the name of readme.md to README.md.
>  * Get rid of build.sh and clean.sh.  They're non-standard and build in
>a weird directory.
>  * Add support for continuous integration.  Travis CI or drone.io are
>good, and maybe AppVeyor if you can figure it out (Windows makes
>*everything* harder).  Every project should be using CI these days.
>  * Use GNUInstallDirs.  For projects indented to place nice on non-
>Windows platforms it makes things a lot easier.
>  * I know this is going to seem self-serving because I wrote it, but
>use configure-cmake.  It helps make cmake's terrible syntax for
>providing arguments much less unpleasant, and helps make projects
>more friendly for people used to autotools.
>  * Disable GCC warnings which are very commonly triggered by correct
>Vala code, starting with -Wincompatible-pointer-types.  For this
>you'll need to detect which flags the compiler supports; I use s://github.com/quixdb/squash/blob/master/cmake/AddCompilerFlags.cmak
>e>, but that may be overkill for you (I have to deal with C++,
>adding additional warning flags, compiler-specific flags, etc.)
>  * Use add_subdirectory() and a CMakeLists.txt in each subdirectory
>instead of a single CMakeLists.txt at the top level; it's much
>easier as your project gets larger, and CMake doesn't have the same
>problems autotools does when you do it.
>  * Add a .gitignore.
>  * Add semantic versioning info to the project, use it to set the
>VERSION and SOVERSION properties of the library.
>  * Write the version information to a config.h, add a config.vapi to
>bind it, then use it in the exectuable to have --version output the
>version.  You may want to also add functions to the library to get
>the library version and include both the library and executable
>versions in the output of --version
>  * Use the option parser built in to glib to parse options and handle
>the --help argument.
>  * Install the executable, library, and public headers.  Don't forget
>about the RUNTIME, LIBRARY, and ARCHIVE destination directories for
>the library (important for people building on Windows).
>  * Handle "Debug" vs. "Release" builds properly… at the very least
>debug should include the -g flag and release should define NDEBUG.
>Remember, though, that you have to check whether -g works (they
>could be using MSVC), you can't just add it directly to the flags.
>  * Add a "dist" target to build a release tarball (you'll probably want
>to use cpack for this).
>
> >
> > Thanks!
> >
> > On Fri, Feb 5, 2016 at 3:44 AM, Evan Nemerson 
> > wrote:
> > > You're missing support for `make test`.
> > >
> > > This is a bit more complicated than it needs to be since recent
> > > versions of CMake will complain if you try to create a "test"
> > > target;
> > > they've decided to reserve it for their ctest framework, so the
> > > only
> > > real choice is to use ctest.
> > >
> > > ctest is really geared towards executing multiple small test
> > > programs
> > > instead of one monolithic test, but you can get around that by
> > > running
> > > the same executable multiple times and having and only executing a
> > > subset of the tests each time.  If you don't, the ctest

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-05 Thread Evan Nemerson

On Fri, 2016-02-05 at 13:34 -0200, Felipe Lavratti wrote:
> This is a nice pull request even, I've merged it.
> 
> Is there a simple way to automatically detect and fill the tests
> lists?

I don't think so.  CMake requires knowledge of the test names at
configure time, so even if you could somehow query the test program for
a list of available tests, it would be too late.

If you were using autotools it would be pretty straightforward, at
least if you're willing to add a bit of code to your test executable to
add an option to enumerate tests (which wouldn't be difficult).  Just
have your test target be something like:

for test in $(test-executable --list-tests); do
  $(test-executable -p "${test}")
done

With cmake, trying to do something similar will not work because they
pretty much force you to use ctest.

> Also, what extra features would be nice to see in this template ?

Some things which come to mind based on a very quick look:

 * Since you're using uncrustify anyways, you should add a pre-commit
   hook to run it and verify that the code meets the formatting
   guidelines you've set.
 * Add valadoc support, at least to the library portion of the project.

 * Add a COPYING or LICENSE file (even if it's just a placeholder that
   tells people to paste their license).
 * Change the name of readme.md to README.md.
 * Get rid of build.sh and clean.sh.  They're non-standard and build in
   a weird directory.
 * Add support for continuous integration.  Travis CI or drone.io are
   good, and maybe AppVeyor if you can figure it out (Windows makes
   *everything* harder).  Every project should be using CI these days.
 * Use GNUInstallDirs.  For projects indented to place nice on non-
   Windows platforms it makes things a lot easier.
 * I know this is going to seem self-serving because I wrote it, but
   use configure-cmake.  It helps make cmake's terrible syntax for
   providing arguments much less unpleasant, and helps make projects
   more friendly for people used to autotools.
 * Disable GCC warnings which are very commonly triggered by correct
   Vala code, starting with -Wincompatible-pointer-types.  For this
   you'll need to detect which flags the compiler supports; I use , but that may be overkill for you (I have to deal with C++,
   adding additional warning flags, compiler-specific flags, etc.)
 * Use add_subdirectory() and a CMakeLists.txt in each subdirectory
   instead of a single CMakeLists.txt at the top level; it's much
   easier as your project gets larger, and CMake doesn't have the same
   problems autotools does when you do it.
 * Add a .gitignore.
 * Add semantic versioning info to the project, use it to set the
   VERSION and SOVERSION properties of the library.
 * Write the version information to a config.h, add a config.vapi to
   bind it, then use it in the exectuable to have --version output the
   version.  You may want to also add functions to the library to get
   the library version and include both the library and executable
   versions in the output of --version
 * Use the option parser built in to glib to parse options and handle
   the --help argument.
 * Install the executable, library, and public headers.  Don't forget
   about the RUNTIME, LIBRARY, and ARCHIVE destination directories for
   the library (important for people building on Windows).
 * Handle "Debug" vs. "Release" builds properly… at the very least
   debug should include the -g flag and release should define NDEBUG.
   Remember, though, that you have to check whether -g works (they
   could be using MSVC), you can't just add it directly to the flags.
 * Add a "dist" target to build a release tarball (you'll probably want
   to use cpack for this).

> 
> Thanks!
> 
> On Fri, Feb 5, 2016 at 3:44 AM, Evan Nemerson 
> wrote:
> > You're missing support for `make test`.
> > 
> > This is a bit more complicated than it needs to be since recent
> > versions of CMake will complain if you try to create a "test"
> > target;
> > they've decided to reserve it for their ctest framework, so the
> > only
> > real choice is to use ctest.
> > 
> > ctest is really geared towards executing multiple small test
> > programs
> > instead of one monolithic test, but you can get around that by
> > running
> > the same executable multiple times and having and only executing a
> > subset of the tests each time.  If you don't, the ctest output will
> > always treat your tests as a single test, and the usefulness of
> > reports
> > will be quite limited.
> > 
> > If you want an example, you can look at
> > 
> > ; it
> > is for C tests using µnit not Vala tests using glib, but that only
> > makes a difference in how you build the executable… the ctest
> > integration part is the same.
> > 
> > Assuming your executable is `my_project_unit_tests', you would want
> > something like this:
> > 
> > # Enable ctest
> >

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-04 Thread Chris Daley

You may also find the Gee.TestCase class suits your needs - it certainly
makes the tests easier to read and is more xUnit like in its approach than
the 'naked' GLib Test classes.

https://esite.ch/2012/06/writing-tests-for-vala/

Gives a good overview - and if I recall the GXml tests that Daniel
mentioned uses it as well.

Cheers
Chris D

2016-02-04 14:09 GMT-08:00 Daniel Espinosa :

> GXml have a test suite may you want to check. I has more than 50 tests
> cases.
> El feb. 4, 2016 3:04 PM, "Al Thomas"  escribió:
>
> >
> >
> > - Original Message -
> > > From: Felipe Lavratti 
> > > Sent: Thursday, 4 February 2016, 20:18
> > > Subject: [Vala] Using TestCase class: assert (this is Object) fails in
> > method, but not in constructor
> > >
> > > Have a look at this code:
> > >
> > > public class Tests : Object {
> > >
> > > public Tests () {
> > > assert (this is Object); // THIS ASSERTION PASSES
> > > ts = new TestSuite ("dot_cap_dimmer") ;
> > > ts.add (new TestCase ("construction", (TestFixtureFunc)
> > > setup, (TestFixtureFunc) test_construction, (TestFixtureFunc)
> > > teardown)) ;
> > > TestSuite.get_root ().add_suite (ts) ;
> > > }
> > >
> > > void setup(void * fixture) {
> > > assert (this is Object);  // THIS ASSERTION FAILS
> > > this.cut = new DotCapDimmer () ;
> > > this.cut.on_change.connect (slot) ;
> > > this.called = false ;
> > > }
> > > ...
> > >  }
> > >
> > > Would anyone know what happens to the `this` variable when called
> > > from the TestCase ? How came it is no longer an Object anymore ?
> >
> >
> > You need to instantiate your fixture so it has `this` to act upon.
> > Your fixture should be a separate object to the test.
> > As an outline;
> >
> >
> > void main( string[] args ) {
> >
> >   Test.init(ref args);
> >   TestSuite suite = new TestSuite( "DotCapDimmer" );
> >   TestSuite.get_root ().add_suite (suite);
> >
> >   MyTestFixture fixture = new MyTestFixture();
> >   suite.add( new TestCase ( "MyFirstTestCase", fixture.set_up,
> > (TestFixtureFunc)test_my_first_test, fixture.tear_down ));
> >   Test.run();
> > }
> >
> > void test_my_first_test( MyTestFixture fixture ) {
> > // do testing
> >
> > }
> >
> >
> >
> > I put the test in a namespace like
> > UnitTest.ModuleDirectory.FilenameOfClassToBeTested
> >
> > There is also g_test_add_data_func_full () instead, but I haven't used
> > that yet.
> >
> > Al
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> >
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



-- 
Chris Daley
Pacific Northwest

e: chebiza...@gmail.com
w: http://chrisdaley.biz
m: +1601 980 1249
s: chebizarro
tw: chebizarro
tz: PDT
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-04 Thread Steven Oliver

I'm in the process of implementing the gee test suite into my project. So far 
so good. The test suite was easy to figure out. So far my biggest problem has 
been trying to figure out how to setup CMake for it all to work. 

Thank you,
Steven N. Oliver 





On Thu, Feb 4, 2016 at 3:07 PM -0800, "Chris Daley"  
wrote:










You may also find the Gee.TestCase class suits your needs - it certainly
makes the tests easier to read and is more xUnit like in its approach than
the 'naked' GLib Test classes.

https://esite.ch/2012/06/writing-tests-for-vala/

Gives a good overview - and if I recall the GXml tests that Daniel
mentioned uses it as well.

Cheers
Chris D

2016-02-04 14:09 GMT-08:00 Daniel Espinosa :

> GXml have a test suite may you want to check. I has more than 50 tests
> cases.
> El feb. 4, 2016 3:04 PM, "Al Thomas"  escribió:
>
> >
> >
> > - Original Message -
> > > From: Felipe Lavratti 
> > > Sent: Thursday, 4 February 2016, 20:18
> > > Subject: [Vala] Using TestCase class: assert (this is Object) fails in
> > method, but not in constructor
> > >
> > > Have a look at this code:
> > >
> > > public class Tests : Object {
> > >
> > > public Tests () {
> > > assert (this is Object); // THIS ASSERTION PASSES
> > > ts = new TestSuite ("dot_cap_dimmer") ;
> > > ts.add (new TestCase ("construction", (TestFixtureFunc)
> > > setup, (TestFixtureFunc) test_construction, (TestFixtureFunc)
> > > teardown)) ;
> > > TestSuite.get_root ().add_suite (ts) ;
> > > }
> > >
> > > void setup(void * fixture) {
> > > assert (this is Object);  // THIS ASSERTION FAILS
> > > this.cut = new DotCapDimmer () ;
> > > this.cut.on_change.connect (slot) ;
> > > this.called = false ;
> > > }
> > > ...
> > >  }
> > >
> > > Would anyone know what happens to the `this` variable when called
> > > from the TestCase ? How came it is no longer an Object anymore ?
> >
> >
> > You need to instantiate your fixture so it has `this` to act upon.
> > Your fixture should be a separate object to the test.
> > As an outline;
> >
> >
> > void main( string[] args ) {
> >
> >   Test.init(ref args);
> >   TestSuite suite = new TestSuite( "DotCapDimmer" );
> >   TestSuite.get_root ().add_suite (suite);
> >
> >   MyTestFixture fixture = new MyTestFixture();
> >   suite.add( new TestCase ( "MyFirstTestCase", fixture.set_up,
> > (TestFixtureFunc)test_my_first_test, fixture.tear_down ));
> >   Test.run();
> > }
> >
> > void test_my_first_test( MyTestFixture fixture ) {
> > // do testing
> >
> > }
> >
> >
> >
> > I put the test in a namespace like
> > UnitTest.ModuleDirectory.FilenameOfClassToBeTested
> >
> > There is also g_test_add_data_func_full () instead, but I haven't used
> > that yet.
> >
> > Al
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> >
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>



-- 
Chris Daley
Pacific Northwest

e: chebiza...@gmail.com
w: http://chrisdaley.biz
m: +1601 980 1249
s: chebizarro
tw: chebizarro
tz: PDT
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list





___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-04 Thread Al Thomas



- Original Message -
> From: Felipe Lavratti 
> Sent: Thursday, 4 February 2016, 20:18
> Subject: [Vala] Using TestCase class: assert (this is Object) fails in 
> method, but not in constructor
> 
> Have a look at this code:
> 
> public class Tests : Object {
> 
> public Tests () {
> assert (this is Object); // THIS ASSERTION PASSES
> ts = new TestSuite ("dot_cap_dimmer") ;
> ts.add (new TestCase ("construction", (TestFixtureFunc)
> setup, (TestFixtureFunc) test_construction, (TestFixtureFunc)
> teardown)) ;
> TestSuite.get_root ().add_suite (ts) ;
> }
> 
> void setup(void * fixture) {
> assert (this is Object);  // THIS ASSERTION FAILS
> this.cut = new DotCapDimmer () ;
> this.cut.on_change.connect (slot) ;
> this.called = false ;
> }
> ...
>  }
> 
> Would anyone know what happens to the `this` variable when called
> from the TestCase ? How came it is no longer an Object anymore ?


You need to instantiate your fixture so it has `this` to act upon.
Your fixture should be a separate object to the test.
As an outline;


void main( string[] args ) {

  Test.init(ref args);
  TestSuite suite = new TestSuite( "DotCapDimmer" );
  TestSuite.get_root ().add_suite (suite);

  MyTestFixture fixture = new MyTestFixture();
  suite.add( new TestCase ( "MyFirstTestCase", fixture.set_up, 
(TestFixtureFunc)test_my_first_test, fixture.tear_down ));
  Test.run();
}

void test_my_first_test( MyTestFixture fixture ) {
// do testing

}



I put the test in a namespace like 
UnitTest.ModuleDirectory.FilenameOfClassToBeTested

There is also g_test_add_data_func_full () instead, but I haven't used that yet.

Al
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-04 Thread Felipe Lavratti

Steven,

Since you brought it, I took the liberty to commit a project template
with my current setup of using Atom + Vala + Gee TestCase +
Cmake.

It is here: https://github.com/felipe-lavratti/vala-unittests-cmake

Hope it helps.


On Thu, Feb 4, 2016 at 9:09 PM, Steven Oliver  wrote:
> I'm in the process of implementing the gee test suite into my project. So far 
> so good. The test suite was easy to figure out. So far my biggest problem has 
> been trying to figure out how to setup CMake for it all to work.
>
> Thank you,
> Steven N. Oliver
>
>
>
>
>
> On Thu, Feb 4, 2016 at 3:07 PM -0800, "Chris Daley"  
> wrote:
>
>
>
>
>
>
>
>
>
>
> You may also find the Gee.TestCase class suits your needs - it certainly
> makes the tests easier to read and is more xUnit like in its approach than
> the 'naked' GLib Test classes.
>
> https://esite.ch/2012/06/writing-tests-for-vala/
>
> Gives a good overview - and if I recall the GXml tests that Daniel
> mentioned uses it as well.
>
> Cheers
> Chris D
>
> 2016-02-04 14:09 GMT-08:00 Daniel Espinosa :
>
>> GXml have a test suite may you want to check. I has more than 50 tests
>> cases.
>> El feb. 4, 2016 3:04 PM, "Al Thomas"  escribió:
>>
>> >
>> >
>> > - Original Message -
>> > > From: Felipe Lavratti
>> > > Sent: Thursday, 4 February 2016, 20:18
>> > > Subject: [Vala] Using TestCase class: assert (this is Object) fails in
>> > method, but not in constructor
>> > >
>> > > Have a look at this code:
>> > >
>> > > public class Tests : Object {
>> > >
>> > > public Tests () {
>> > > assert (this is Object); // THIS ASSERTION PASSES
>> > > ts = new TestSuite ("dot_cap_dimmer") ;
>> > > ts.add (new TestCase ("construction", (TestFixtureFunc)
>> > > setup, (TestFixtureFunc) test_construction, (TestFixtureFunc)
>> > > teardown)) ;
>> > > TestSuite.get_root ().add_suite (ts) ;
>> > > }
>> > >
>> > > void setup(void * fixture) {
>> > > assert (this is Object);  // THIS ASSERTION FAILS
>> > > this.cut = new DotCapDimmer () ;
>> > > this.cut.on_change.connect (slot) ;
>> > > this.called = false ;
>> > > }
>> > > ...
>> > >  }
>> > >
>> > > Would anyone know what happens to the `this` variable when called
>> > > from the TestCase ? How came it is no longer an Object anymore ?
>> >
>> >
>> > You need to instantiate your fixture so it has `this` to act upon.
>> > Your fixture should be a separate object to the test.
>> > As an outline;
>> >
>> >
>> > void main( string[] args ) {
>> >
>> >   Test.init(ref args);
>> >   TestSuite suite = new TestSuite( "DotCapDimmer" );
>> >   TestSuite.get_root ().add_suite (suite);
>> >
>> >   MyTestFixture fixture = new MyTestFixture();
>> >   suite.add( new TestCase ( "MyFirstTestCase", fixture.set_up,
>> > (TestFixtureFunc)test_my_first_test, fixture.tear_down ));
>> >   Test.run();
>> > }
>> >
>> > void test_my_first_test( MyTestFixture fixture ) {
>> > // do testing
>> >
>> > }
>> >
>> >
>> >
>> > I put the test in a namespace like
>> > UnitTest.ModuleDirectory.FilenameOfClassToBeTested
>> >
>> > There is also g_test_add_data_func_full () instead, but I haven't used
>> > that yet.
>> >
>> > Al
>> > ___
>> > vala-list mailing list
>> > vala-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/vala-list
>> >
>> ___
>> vala-list mailing list
>> vala-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/vala-list
>>
>
>
>
> --
> Chris Daley
> Pacific Northwest
>
> e: chebiza...@gmail.com
> w: http://chrisdaley.biz
> m: +1601 980 1249
> s: chebizarro
> tw: chebizarro
> tz: PDT
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
>
>
>
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list



-- 
Skype: felipeanl
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-04 Thread Chris Daley

Hi Felipe,

I was just hoping someone would do exactly this! I don't know CMake very
well but would like to make Valadate work with it, and I needed a sample
project to get started. This is perfect.

I just have one question, does this run the compiled test binary through
gtester (or other test runner) or does it just execute it?

Muito obrigado!
Chris

2016-02-04 19:31 GMT-08:00 Felipe Lavratti :

> Steven,
>
> Since you brought it, I took the liberty to commit a project template
> with my current setup of using Atom + Vala + Gee TestCase +
> Cmake.
>
> It is here: https://github.com/felipe-lavratti/vala-unittests-cmake
>
> Hope it helps.
>
>
> On Thu, Feb 4, 2016 at 9:09 PM, Steven Oliver 
> wrote:
> > I'm in the process of implementing the gee test suite into my project.
> So far so good. The test suite was easy to figure out. So far my biggest
> problem has been trying to figure out how to setup CMake for it all to work.
> >
> > Thank you,
> > Steven N. Oliver
> >
> >
> >
> >
> >
> > On Thu, Feb 4, 2016 at 3:07 PM -0800, "Chris Daley" <
> chebiza...@gmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > You may also find the Gee.TestCase class suits your needs - it certainly
> > makes the tests easier to read and is more xUnit like in its approach
> than
> > the 'naked' GLib Test classes.
> >
> > https://esite.ch/2012/06/writing-tests-for-vala/
> >
> > Gives a good overview - and if I recall the GXml tests that Daniel
> > mentioned uses it as well.
> >
> > Cheers
> > Chris D
> >
> > 2016-02-04 14:09 GMT-08:00 Daniel Espinosa :
> >
> >> GXml have a test suite may you want to check. I has more than 50 tests
> >> cases.
> >> El feb. 4, 2016 3:04 PM, "Al Thomas"  escribió:
> >>
> >> >
> >> >
> >> > - Original Message -
> >> > > From: Felipe Lavratti
> >> > > Sent: Thursday, 4 February 2016, 20:18
> >> > > Subject: [Vala] Using TestCase class: assert (this is Object) fails
> in
> >> > method, but not in constructor
> >> > >
> >> > > Have a look at this code:
> >> > >
> >> > > public class Tests : Object {
> >> > >
> >> > > public Tests () {
> >> > > assert (this is Object); // THIS ASSERTION PASSES
> >> > > ts = new TestSuite ("dot_cap_dimmer") ;
> >> > > ts.add (new TestCase ("construction", (TestFixtureFunc)
> >> > > setup, (TestFixtureFunc) test_construction, (TestFixtureFunc)
> >> > > teardown)) ;
> >> > > TestSuite.get_root ().add_suite (ts) ;
> >> > > }
> >> > >
> >> > > void setup(void * fixture) {
> >> > > assert (this is Object);  // THIS ASSERTION FAILS
> >> > > this.cut = new DotCapDimmer () ;
> >> > > this.cut.on_change.connect (slot) ;
> >> > > this.called = false ;
> >> > > }
> >> > > ...
> >> > >  }
> >> > >
> >> > > Would anyone know what happens to the `this` variable when called
> >> > > from the TestCase ? How came it is no longer an Object anymore ?
> >> >
> >> >
> >> > You need to instantiate your fixture so it has `this` to act upon.
> >> > Your fixture should be a separate object to the test.
> >> > As an outline;
> >> >
> >> >
> >> > void main( string[] args ) {
> >> >
> >> >   Test.init(ref args);
> >> >   TestSuite suite = new TestSuite( "DotCapDimmer" );
> >> >   TestSuite.get_root ().add_suite (suite);
> >> >
> >> >   MyTestFixture fixture = new MyTestFixture();
> >> >   suite.add( new TestCase ( "MyFirstTestCase", fixture.set_up,
> >> > (TestFixtureFunc)test_my_first_test, fixture.tear_down ));
> >> >   Test.run();
> >> > }
> >> >
> >> > void test_my_first_test( MyTestFixture fixture ) {
> >> > // do testing
> >> >
> >> > }
> >> >
> >> >
> >> >
> >> > I put the test in a namespace like
> >> > UnitTest.ModuleDirectory.FilenameOfClassToBeTested
> >> >
> >> > There is also g_test_add_data_func_full () instead, but I haven't used
> >> > that yet.
> >> >
> >> > Al
> >> > ___
> >> > vala-list mailing list
> >> > vala-list@gnome.org
> >> > https://mail.gnome.org/mailman/listinfo/vala-list
> >> >
> >> ___
> >> vala-list mailing list
> >> vala-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/vala-list
> >>
> >
> >
> >
> > --
> > Chris Daley
> > Pacific Northwest
> >
> > e: chebiza...@gmail.com
> > w: http://chrisdaley.biz
> > m: +1601 980 1249
> > s: chebizarro
> > tw: chebizarro
> > tz: PDT
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
> >
> >
> >
> >
> >
> > ___
> > vala-list mailing list
> > vala-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/vala-list
>
>
>
> --
> Skype: felipeanl
>



-- 
Chris Daley
Pacific Northwest

e: chebiza...@gmail.com
w: http://chrisdaley.biz
m: +1601 980 1249
s: chebizarro
tw: chebizarro

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-04 Thread Evan Nemerson

You're missing support for `make test`.

This is a bit more complicated than it needs to be since recent
versions of CMake will complain if you try to create a "test" target;
they've decided to reserve it for their ctest framework, so the only
real choice is to use ctest.

ctest is really geared towards executing multiple small test programs
instead of one monolithic test, but you can get around that by running
the same executable multiple times and having and only executing a
subset of the tests each time.  If you don't, the ctest output will
always treat your tests as a single test, and the usefulness of reports
will be quite limited.

If you want an example, you can look at
; it
is for C tests using µnit not Vala tests using glib, but that only
makes a difference in how you build the executable… the ctest
integration part is the same.

Assuming your executable is `my_project_unit_tests', you would want
something like this:

# Enable ctest
enable_testing()

# Build your executable here, you'll have to figure this part out
# on your own, it's project-specific.
add_executable(my_project_unit_tests …)

# List of tests in the `my_project_unit_tests' executable that you
# want to execute.  The project currently only has a single test,
# "/my_class/foo", so I've added a few more so you get the idea.
set(MY_PROJECT_TESTS
  /my_class/foo
  /my_class/bar
  /my_class/baz
  /your_class)

foreach(test_name ${MY_PROJECT_TESTS})
  add_test(NAME ${test_name}
COMMAND $ -p ${test_name})
endforeach(test_name)

The only line here that really needs an explanation is the second to
last.  The $<…> thing is a generator expression; see .  In that
case it will just be the path to the my_project_unit_tests executable.
 The `-p ${test_name}' part just tells the executable to execute only a
specific test instead of all of them.

Once you're done, you should be able to run the tests with either `make
test` or by just running `ctest` directly.

Also, instead of the build.sh script, I'd like to suggest
.

-Evan

On Fri, 2016-02-05 at 01:31 -0200, Felipe Lavratti wrote:
> Steven,
> 
> Since you brought it, I took the liberty to commit a project template
> with my current setup of using Atom + Vala + Gee TestCase +
> Cmake.
> 
> It is here: https://github.com/felipe-lavratti/vala-unittests-cmake
> 
> Hope it helps.
> 
> 
> On Thu, Feb 4, 2016 at 9:09 PM, Steven Oliver  m> wrote:
> > I'm in the process of implementing the gee test suite into my
> > project. So far so good. The test suite was easy to figure out. So
> > far my biggest problem has been trying to figure out how to setup
> > CMake for it all to work.
> > 
> > Thank you,
> > Steven N. Oliver
> > 
> > 
> > 
> > 
> > 
> > On Thu, Feb 4, 2016 at 3:07 PM -0800, "Chris Daley"  > il.com> wrote:
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > You may also find the Gee.TestCase class suits your needs - it
> > certainly
> > makes the tests easier to read and is more xUnit like in its
> > approach than
> > the 'naked' GLib Test classes.
> > 
> > https://esite.ch/2012/06/writing-tests-for-vala/
> > 
> > Gives a good overview - and if I recall the GXml tests that Daniel
> > mentioned uses it as well.
> > 
> > Cheers
> > Chris D
> > 
> > 2016-02-04 14:09 GMT-08:00 Daniel Espinosa :
> > 
> > > GXml have a test suite may you want to check. I has more than 50
> > > tests
> > > cases.
> > > El feb. 4, 2016 3:04 PM, "Al Thomas"  escribió:
> > > 
> > > > 
> > > > 
> > > > - Original Message -
> > > > > From: Felipe Lavratti
> > > > > Sent: Thursday, 4 February 2016, 20:18
> > > > > Subject: [Vala] Using TestCase class: assert (this is Object)
> > > > > fails in
> > > > method, but not in constructor
> > > > > 
> > > > > Have a look at this code:
> > > > > 
> > > > > public class Tests : Object {
> > > > > 
> > > > > public Tests () {
> > > > > assert (this is Object); // THIS ASSERTION PASSES
> > > > > ts = new TestSuite ("dot_cap_dimmer") ;
> > > > > ts.add (new TestCase ("construction",
> > > > > (TestFixtureFunc)
> > > > > setup, (TestFixtureFunc) test_construction, (TestFixtureFunc)
> > > > > teardown)) ;
> > > > > TestSuite.get_root ().add_suite (ts) ;
> > > > > }
> > > > > 
> > > > > void setup(void * fixture) {
> > > > > assert (this is Object);  // THIS ASSERTION FAILS
> > > > > this.cut = new DotCapDimmer () ;
> > > > > this.cut.on_change.connect (slot) ;
> > > > > this.called = false ;
> > > > > }
> > > > > ...
> > > > >  }
> > > > > 
> > > > > Would anyone know what happens to the

[Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

2016-02-04 Thread Felipe Lavratti

Have a look at this code:

public class Tests : Object {

public Tests () {
assert (this is Object); // THIS ASSERTION PASSES
ts = new TestSuite ("dot_cap_dimmer") ;
ts.add (new TestCase ("construction", (TestFixtureFunc)
setup, (TestFixtureFunc) test_construction, (TestFixtureFunc)
teardown)) ;
TestSuite.get_root ().add_suite (ts) ;
}

void setup(void * fixture) {
assert (this is Object);  // THIS ASSERTION FAILS
this.cut = new DotCapDimmer () ;
this.cut.on_change.connect (slot) ;
this.called = false ;
}
...
 }

Would anyone know what happens to the `this` variable when called
from the TestCase ? How came it is no longer an Object anymore ?

-- 
Skype: felipeanl
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

Re: [Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

[Vala] Using TestCase class: assert (this is Object) fails in method, but not in constructor

11 matches

Site Navigation

Mail list logo

Footer information