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 +0000, 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 <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 c om> 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://c make .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 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