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-cmake Hope it helps. On Thu, Feb 4, 2016 at 9:09 PM, Steven Oliver <oliver steven gmail 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 inmethod, but not in constructorHave 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
Attachment:
signature.asc
Description: This is a digitally signed message part