GNOME.org
 

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

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 <evan coeus-group com> 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 <http
   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 <evan coeus-group com>
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
<https://github.com/quixdb/squash/blob/master/tests/CMakeLists.txt>
; 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 $<TARGET_FILE:my_project_unit_tests> -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 <https://cmake
.org
/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.

<shameless-plug>
Also, instead of the build.sh script, I'd like to suggest
<https://github.com/nemequ/configure-cmake/>.
</shameless-plug>


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

Hope it helps.


On Thu, Feb 4, 2016 at 9:09 PM, Steven Oliver <oliver steven gmai
l.co
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" <chebizarro
@gma
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 `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: chebizarro 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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]