[Libguestfs] [PATCH 0/2] Add lightweight bindings for PCRE.

Richard W.M. Jones rjones at redhat.com
Fri Aug 4 08:01:28 UTC 2017


You asked me to reply to some other points (copied from
https://www.redhat.com/archives/libguestfs/2017-July/msg00189.html):

> Sure.  OTOH, we already do use oUnit2, so these reasonings were already
> discussed in the past, and (considered we have tests based on oUnit2)
> deemed not a problem.

I don't think that every past decision should be unchangable.

> What I still don't understand is why adding a new test based on oUnit2
> would be a problem, while the rest of the tests are fine as they are.

I think we should remove oUnit tests and replace them with asserts.
But it's not of such critical importance that we need to do that right
now, or even soon.  However adding more oUnit tests means adding more
tests which can't be run unless you have oUnit installed.

> > If packagers don't have it and they run the tests then the oUnit2
> > tests are skipped (see ‘if HAVE_OCAML_PKG_OUNIT’ in the makefiles).
> 
> Packagers rarely run our unit tests, since they make the build times
> much longer, even on fast builders.  (Not to mention that sometimes
> they use VMs, and thus this adds more issues to that.)  Even in Fedora
> the general test suite is disabled, only `make quickcheck` is run.
> This means it is mostly us developers (or CI) building and testing the
> full test suite.

[Although it's incidental to this, I should say that in Fedora the
full test suite is enabled, it's just run in two different places (not
Koji because of the complexity and time involved running it in Koji).
‘make check-release’ is run when the tarball is built, and ‘make
installcheck’ is run manually by me after the package has been built.]

> Regarding the availability: oUnit2 is available in the latest stable
> versions of all the major distros, even in older versions.
> 
> > A simpler test framework which didn't use an external dependency
> > wouldn't be skipped.
> 
> Surely I'm not an expert OCaml hacker, but at least to me oUnit2 does
> not seem that complex, and a manually written framework would end up
> reimplementing most of it, in the end.

If you compare an oUnit test:

  https://github.com/libguestfs/libguestfs/blob/master/common/mlutils/c_utils_unit_tests.ml

to an assert test:

  https://github.com/libguestfs/libguestfs/blob/master/daemon/daemon_utils_tests.ml

There is barely any difference to me.  This is my point really: oUnit
doesn't bring any particular benefit.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/




More information about the Libguestfs mailing list