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 <e...@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 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
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
