This bug has been migrated from artifact #1168 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2012-09-05 03:55:22.

user116 posted on 2012-06-07 08:17:55:

Release 1.1.1 is not ready for ocaml 4.0.

$ PATH=/opt/ocaml-4.00.0+beta2/bin:$PATH make
[...]
ocaml setup.ml -build
I: Running command '/opt/ocaml-4.00.0+beta2/bin/ocamlbuild src/oUnit.cma src/oUnit.cmxa src/oUnit.a test/test.byte -tag debug'
Finished, 1 target (0 cached) in 00:00:00.
Finished, 15 targets (0 cached) in 00:00:01.
ocaml setup.ml -test
I: Running test 'main'
E: Field 'test' is not set: Malformed log file '/home/user/temp/ounit-1.1.1/setup.log' at line 1
make: *** [test] Error 1

See also : http://groups.google.com/group/fa.caml/browse_thread/thread/e2c465126792ccfd

This feature request has been migrated from artifact #638 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2010-10-05 12:58:40.

user102 posted on 2010-05-25 10:33:29:

It should display all available tests

This bug has been migrated from artifact #1323 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 08:22:23.

user116 posted on 2013-09-30 03:45:29:

Looks like cmo files are not installed after make && make install
Witness :
make install |& grep cmo
<empty output>

user116 replied on 2013-09-30 03:46:28:

This is for 2.0.0

user116 replied on 2013-09-30 03:51:21:

Sorry, disregard this bugreport, I cannot compile bytecode binary with ounit 2.0.0 but have not yet identified the reason

user102 replied on 2013-09-30 06:51:26:

The .cma should be enough. Please send me update when you have solved the compilation problem.

user116 replied on 2013-09-30 07:00:24:

Correct. No bug here. This was an old project without ocamlfind so it missed oUnitAdvanced.cma during linking.

This bug has been migrated from artifact #637 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2010-10-05 12:58:07.

user102 posted on 2010-05-25 10:32:43:

The only-test remove tests and change the test numbering. It is better to skip tests and have a stable numbering scheme.

This bug has been migrated from artifact #1757 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-08-27 06:52:14.

user25897 posted on 2017-08-30 11:10:52:

Youtube video is down

This bug has been migrated from artifact #1356 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-09-27 14:02:13.

user116 posted on 2013-12-02 08:31:01:

In the following code (from the ocamldoc comments) :

open OUnit2;;

let my_program =
Conf.make_exec "my_program"
;;

let test1 test_ctxt =
assert_command (my_program test_ctxt) []
;;

let () =
run_test_tt_main ("test1" >:: test1)
;;

assert_command should take named ctxt parameter

user102 replied on 2019-09-27 14:02:13:

This has been fixed by rewriting the example:
gildor478/ounit@79170b2#diff-bfebe34154a0dfd9fc7b447fc9ed74e9

This patch has been migrated from artifact #1262 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:41:28.

user11011 posted on 2013-03-03 12:12:22:

Hello,

I work this morning on the multi-threading of OUnit2, feature-request #1095

I've patched OUnitCore and _oasis. Seems to works but I don't know if adding threads in the BuildDepends section is the correct way to add thread support, does it add the -thread flag ?

However, tests shows that OUnit is running in parallel in the processus point of view.

I choose the thread approach because in OCaml, processes will be a far more heavy solution for... what benefits ?
As threads are system threads, they are preemptive, are they ? (The doc says so, I've always learn so, but you don't feel so in the FR...). Timeouts can be managed with threads also, just add a watchdog for each thread test.
Moreover, the cost of process creation comparing to the running time of a little OUnit test is a bit unfair.
That's why threads seems to be the Right Thing.

I used a thread pool to minimize the cost of thread creation, keeping in mind that tests should be small. Maybe the pool size should be adjusted, It's quiet easy.

Please review my patch and help me test, I'm far from confident with oasis.
I only give you oUnitCore.ml, I think you'll know better than me how to change _oasis. ;-)

Attached: patch in whatsnew and diff format

user102 replied on 2013-03-03 19:55:38:

Thanks for the patch.

Unfortunately, thread in OCaml are not what you expect they are (that is a long standing issue in OCaml).

If your read the doc about threads:
http://caml.inria.fr/pub/docs/manual-ocaml/manual039.html

The threads library is implemented by time-sharing on a single processor. It will not take advantage of multi-processor machines. Using this library will therefore never make programs run faster. However, many programs are easier to write when structured as several communicating processes.

That is not 100% clear, but I can give you an explanation. The Threads library should be used for concurrency and not parallelism. Whenever a program run it acquires a "big lock" that prevents any other OCaml code to run. The only exception is when entering special part of the OCaml runtime that release the lock (like file reading).

So Yes, processus creation is heavy but is the only to get true parallelism in OCaml.

user11011 replied on 2013-03-05 21:09:06:

Damn ! I was sure this issue was gone with Ocaml 4. You should specify it here: http://ocamlunix.forge.ocamlcore.org/threads.html

Ok, so what do we do ?

Do we keep that ? Or are we playing with myocamlbuild.ml in order to register tests as binary targets ?

I the latter case, I think we should give the right to the dev to choose for each test if it should be in its own process or not, by example in introducing a new test_case operator (which one ?).

We can also make a pool of process and play with marshalling/S-exp and IPC to transfer our tests (do the Marshalling keep closures ?).

An advice ? I personally have a preference for the last solution, but only because it's seems far more fun.

user102 replied on 2013-03-05 22:07:45:

fork + marshalling + select.

You fork X process, and you send to each process a test to run (since they have been forked, they share the same definition). And then you select to wait for one of the forked process to send back the result -- and assign a new one.

(your last solution).

user11011 replied on 2013-03-05 22:12:36:

So be it.

I'll work on that very soon.

user102 replied on 2013-03-08 13:56:21:

I plan to release oUnit next week or th week following.

If you have made any progress on this patches, keep me updated so that we don't do the wor twice.

Although don't hesitate to send me an incomplete patch, just leave TODO item inside it.

user11011 replied on 2013-03-16 18:08:57:

Hello Sylvain, sorry for the latency, I was busy last week.

I have worked a bit on OUnit : https://gist.github.com/mackwic/5177470
There is a new file: oUnitWorker, basically a simple process that loop reading on a socket.
In oUnitCore.ml, run_all_test has been split in 3: run_all_test_{seq, threaded, process}. I didn't see any regression with sequential and threaded runners.
The by-process runner is not terminated, as I'm not very confident with sockets in Ocaml and I lack of time to polish it. You can see the documented TODO to fill.
It ``only'' miss the select & read/write part of the main process.

If you have already worked on a piece of code, use yours, that's really not a problem. ;-)

user102 replied on 2013-03-23 00:01:40:

I have patched OUnit to use your changes.

http://darcs.ocamlcore.org/cgi-bin/darcsweb.cgi?r=ounit/ounit;a=commit;h=20130322234849-4d692-faf5ac417afc820a5164127cd599f5e98c47ff6d.gz

This feature request has been migrated from artifact #874 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:38:13.

user102 posted on 2011-01-14 14:46:20:

Just as OUnit.bracket_tmpfile, a function should create a temporary directory.

user102 replied on 2013-09-30 00:38:13:

Close with OUnit v2.0.0.

This bug has been migrated from artifact #643 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2010-10-05 12:58:07.

user102 posted on 2010-05-25 10:45:00:

With v1.0.3 the exit code is always 0.

This patch has been migrated from artifact #799 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2012-02-22 21:42:05.

user102 posted on 2010-11-03 14:31:01:

It would be useful to make return value of the testfunction f and teardown in
OUnit.bracket "unit" to enforce typing to avoid accidentally returning a
monadic type causing partial execution of a testcase. (e.g. when using Lwt)

See attached patch for a proposed solution.

Thanks, Joost Damad

This bug has been migrated from artifact #1082 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2012-01-18 20:42:25.

user4283 posted on 2012-01-15 17:23:47:

The function only uses the compare function in the DIFF_ELEMENT module for the first element. To fix, change "let compare =" to "let rec compare =".

This bug has been migrated from artifact #1548 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-09-27 14:04:13.

user102 posted on 2016-06-02 20:52:47:

There are some line with blank at EOL. Examples:
2016-06-02T20:41:31+00:00 zetta#01 I: Environment:
2016-06-02T20:41:31+00:00 zetta#01 I:
2016-06-02T20:41:31+00:00 zetta#01 E:

I expect no blank at the end of lines.

user102 replied on 2019-09-27 14:04:13:

Fixed with the improved way to log variables:
gildor478/ounit@ca81492

This feature request has been migrated from artifact #862 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:38:04.

user824 posted on 2011-01-04 13:08:32:

there should be a way in ounit to use timeouts.
I can sort of do that now with something like this (see below), but I guess it won't work on windows, and won't work if ounit ever learns to run the tests in parallel.
Also it doesn't work if the testcase throws a stack overflow, (or otherwise wants to segfault), setting a signal handler will just keep ocaml in an infinite loop.

So I think ounit should have a way to run tests in subprocesses, that way I can tell exactly which test failed, and timeouts would work better (killing process won't kill entire testsuite), and you can also easily run multiple tests in parallel if you decide to support that in the future.
Of course spawning a process is not a cheap task, so this should be configurable (optional param to run_test_tt_main?) and by default off.

open OUnit;;
let rec forever () = forever ();;

let test1 () =
Unix.alarm 2;
forever ();;

let suite =
"suite">:::["test1">:: test1];;

let _ =
Sys.signal 14 (Sys.Signal_handle (fun _ -> failwith "timeout"));
run_test_tt_main suite;

user102 replied on 2011-01-14 14:44:59:

There are other possibilities:

• use thread and Thread.kill after a timeout
• use Lwt and Lwt.cancel

Need to think about it, this is not an easy feature request.

user102 replied on 2013-09-30 00:38:04:

Close with OUnit v2.0.0.

Timeout is handled in the processes runner. I'll may implement the alarm as well for sequential in future release.

This bug has been migrated from artifact #1765 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-09-22 12:07:52.

user30287 posted on 2019-03-25 15:06:01:

The reproducer (test.ml) that I attached to this issue triggers the deadlock (100% CPU) about once every 3 attempts.

If I kill the process when it's infinitely looping, I get the following stack trace:

Fatal error: exception Unix.Unix_error(Unix.EINTR, "select", "")
Raised by primitive operation at file "src/oUnitRunnerProcesses.ml", line 244, characters 4-44
Called from file "src/oUnitRunner.ml", line 444, characters 10-61
Called from file "src/oUnitRunner.ml", line 519, characters 19-41
Called from file "src/oUnitUtils.ml", line 176, characters 12-15
Called from file "src/oUnitCore.ml", line 83, characters 4-59
Called from file "src/oUnitCore.ml", line 172, characters 10-55
Called from file "tests/functional/test_all.ml", line 11, characters 2-24

OCaml version: 4.07.1

Installed libraries:

lwt (version: 4.1.0)
lwt.unix (version: 4.1.0)
oUnit (version: 2.0.8)
oUnit.advanced (version: 2.0.8)
oUnit.threads (version: 2.0.8)
result (version: 1.3)

The issue also appears on OUnit 2.0.6. On earlier versions, I encounter the old issue: https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=1363&group_id=162&.

user102 replied on 2019-09-01 22:39:16:

I have done a few debugging on this. You are using "processes" runner which in turns use the standard Unix.fork which is not great to use in conjunction with Lwt. If we wanted OUnit + processes to work with Lwt, we would need to use Lwt_unix.

The very simple way to solve this problem is to use the "sequential" runner, which doesn't show the same type of problem.

I'll try to fix this bug by preventing to use "processes" when Lwt is used.

user102 replied on 2019-09-22 12:07:52:

I have created ounit-lwt [1] to solve this issue. The test that I have written for this precise bug [2] is passing with the modification to Unix.fork done for ounit-lwt.

[1] gildor478/ounit@348a9c4
[2] https://github.com/gildor478/ounit/blob/master/test/lwt/testRunnerProcesses/testRunnerProcesses.ml

This patch has been migrated from artifact #639 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2010-06-22 11:57:17.

user102 posted on 2010-05-25 10:38:57:

Attached is a patch for oUnit which does the following:

• Augments RError and RFailure with an additional string option element
  to store a backtrace.
• Adds code to test runner to store the backtrace in the result if
  backtraces are enabled.
• Adds code to reporting to print backtraces with the error/failure
  report.
• Modifies the Makefile to compile everything with -g (so stack traces
  don't get lost in oUnit).

From Michael Ekstrand

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528603

This feature request has been migrated from artifact #635 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2010-10-05 16:16:32.

user102 posted on 2010-05-25 10:16:45:

If there is a lot of data, it is hard to find what is different. With a diff operation you do the comparison and only output what is worth (it should also triggers using an ellipsis for the printer, i.e. "aazegmsjlgsljkgsdlm" -> "aaze[...]dlm").

This bug has been migrated from artifact #1363 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-08-27 06:49:42.

user16036 posted on 2014-01-18 00:45:40:

When running my tests, I started getting this error consistently:

Fatal error: exception Unix.Unix_error(11, "select", "")
Raised by primitive operation at unknown location
Called from file "src/oUnitRunnerProcesses.ml", line 191, characters 32-56
Called from file "src/oUnitRunnerProcesses.ml", line 213, characters 14-54
Called from file "src/oUnitRunner.ml", line 358, characters 15-37
Called from file "list.ml", line 84, characters 24-34
Called from file "src/oUnitRunner.ml", line 462, characters 21-43
Called from file "src/oUnitRunner.ml", line 499, characters 18-36
Called from file "src/oUnitUtils.ml", line 172, characters 12-15
Called from file "src/oUnitCore.ml", line 83, characters 4-59
Called from file "src/oUnitCore.ml", line 172, characters 10-55
Called from file "test/test.ml", line 5, characters 1-89

Using git bisect, I tracked this down to first appearing with the commit that first introduced lwt as a dependency in my project (although I don't believe any of my unit tests actually exercise any lwt code).

Running with -runner sequential makes this problem go away, so I presume it's something specific to the process runner. I could try to put together a minimal test case if the above stacktrace isn't sufficient, but it might be quite hard (I can't really tell what's causing it, and I'm still quite new to ocaml). So I'm hoping the above details are sufficient.

user102 replied on 2014-01-21 08:09:27:

I already got a patch for that, will apply for the next release.

user16036 replied on 2014-01-21 20:58:10:

Great, thanks - the workaround of the sequential runner is fine for me (my tests take <1s), but thought it worth reporting :)

user15895 replied on 2014-06-05 13:26:25:

I sent this fix a while back, but I don't see it in the code repository, so posting it here in case anyone else needs it.

From cf340e0fb496d8b120f9b0528b8243fdf6f592c2 Mon Sep 17 00:00:00 2001
From: Thomas Leonard <[email protected]>
Date: Mon, 25 Nov 2013 11:54:49 +0000
Subject: [PATCH] Restart select call if it gets interrupted

src/oUnitRunnerProcesses.ml | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/oUnitRunnerProcesses.ml b/src/oUnitRunnerProcesses.ml
index 5a1466d..498f5cc 100644
--- a/src/oUnitRunnerProcesses.ml
+++ b/src/oUnitRunnerProcesses.ml
@@ -186,14 +186,18 @@ let create_worker conf map_test_cases shard_id master_id worker_log_file =
false, None
end else begin
let running = is_running () in

•            if running then
  

•            if running then begin
               (* Wait 0.1 seconds and continue. *)
  

•              let _, _, _ = Unix.select [] [] [] 0.1 in
  

•                wait_end (timeout -. 0.1)
  

•            else
  

•              begin
  

•                try ignore (Unix.select [] [] [] 0.1)
  

•                with Unix.Unix_error (Unix.EINTR, "select", "") -> ()
  

•              end;
  

•              wait_end (timeout -. 0.1)
  

•            end else begin
               match !rstatus with
               | Some status -> true, msg_of_process_status status
               | None -> true, None
  

•            end
         end
       in
  

--
1.8.4.2

This feature request has been migrated from artifact #641 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2010-10-05 12:58:40.

user102 posted on 2010-05-25 10:40:20:

Define a assert_command that runs a command and compare its exit code and output

This feature request has been migrated from artifact #1109 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:40:03.

user102 posted on 2012-03-07 23:12:34:

Don't display the verbose output but store it in a file. So that you don't have to run it twice.

user102 replied on 2013-09-30 00:39:57:

Close with OUnit v2.0.0.

This bug has been migrated from artifact #1744 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-08-27 06:44:29.

user24482 posted on 2017-03-13 16:38:15:

The function OUnitCore.run_test_tt_main (and its alias in the OUnit2
module) adds the parameter "-output-junit-file" into the CLI. The
program raises a Not_found exception when using this parameter.

You can reproduce by editing examples/example.ml to open OUnit2 instead
of OUnit, compiling it and then launching it like follow:

$ ./example -output-junit-file junit-report.xml
.F

Error: OUnit Example:0:test_list_length.

File "/Users/antoine/Documents/work/ounit/_build/oUnit-OUnit Example-decoy-octopus.local#01.log", line 2, characters 1-1:
Error: OUnit Example:0:test_list_length (in the log).

File "example.ml", line 39, characters 1-1:
Error: OUnit Example:0:test_list_length (in the code).

not equal

Ran: 2 tests in: 0.13 seconds.
FAILED: Cases: 2 Tried: 2 Errors: 0 Failures: 1 Skip: 0 Todo: 0 Timeouts: 0.
Fatal error: exception Not_found
Raised by primitive operation at unknown location
Called from file "src/oUnitUtils.ml", line 214, characters 14-56
Called from file "src/oUnitLoggerJUnit.ml", line 75, characters 17-26
Called from file "src/oUnitLoggerJUnit.ml", line 58, characters 4-496
Called from file "list.ml", line 77, characters 12-15
Called from file "src/oUnitCore.ml", line 95, characters 4-28
Called from file "src/oUnitCore.ml", line 172, characters 10-55
Called from file "example.ml", line 50, characters 2-24

user27159 replied on 2018-01-15 05:54:48:

This pull fixes this issue: gildor478/ounit#5

This feature request has been migrated from artifact #1099 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:39:50.

user102 posted on 2012-02-22 21:49:37:

The vim quickfix is confused by the output of OUnit and tends to redirect to random file (most of the time, non existing one).

It should be great to save the output of OUnit and make vim redirect to the output.

user102 replied on 2013-09-30 00:39:50:

Close with OUnit v2.0.0.

This feature request has been migrated from artifact #642 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2010-10-05 16:16:32.

user102 posted on 2010-05-25 10:40:47:

Add some diff classical operations: diff_string, diff_list, diff_file

This bug has been migrated from artifact #983 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2012-01-18 20:39:58.

user146 posted on 2011-06-02 17:14:00:

The "darcs get" command given on the Contribute page is the following:
$> darcs get http://darcs.ocamlcore.org/repos/ounit/ounit

It doesn't work on my machine, I had to use instead:
$> darcs get http://darcs.ocamlcore.org/repos/ounit

user102 replied on 2012-01-18 20:39:58:

Now ounit/ounit works.

This feature request has been migrated from artifact #1151 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:40:53.

user102 posted on 2012-05-09 23:32:33:

Stderr is most of the time more useful than stdout when failing.

user102 replied on 2013-09-30 00:40:53:

Close with OUnit v2.0.0.

This bug has been migrated from artifact #1433 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-08-27 06:51:59.

user834 posted on 2014-10-14 14:47:33:

I really wanted to try OUnit, which seems the canonical testing framework for OCaml at the moment, but I found it hard to find information about it:

• searching "ounit" in Google gives forge.ocamlcore.org/projects/ounit/ as the 10th result (I had to scroll down) [1]

After that, there is indeed the forge page, where manual.txt is accessible by following 5 non-obvious links (http://forge.ocamlcore.org/scm/browser.php?group_id=162&repo_name=ounit).

May I suggest that:

• the documentation be hosted it in a stable place (preferably in a rendered form instead of raw .txt)
• this documentation be linked prominently from the project homepage on the forge
• the "doc" and "homepage" fields of the OPAM fields be set (this seems easy and I will do it if you don't mind)
• the project homepage mention explicitly that this is the canonical homepage for OUnit, and not one of the several clones or old pages
• the precedent maintainer be asked to remove the old documentation from his site (his/her homepage already points to the forge OUnit homepage)
• your (Sylvain's) blog post be fixed to point to active links ?

I have no idea if the above will be enough to convince Google that the forge is indeed the best place to find info about OUnit, but at least it should make it less painful for the motivated would-be user.

--
Notes:
[1] the links that come before that give several wrong tracks:

• http://mmzeeman.home.xs4all.nl/ocaml/ounit-doc/OUnit.html (link to documentation for some unspecified old version)
• a Youtube OUnit tutorial (!)
• the OPAM page, useful because it confirms that OUnit is not dead (used by many projects), but no link to a homepage or any documentation there
• a blog entry about OUnit 2.0 being released one year ago, where "documentation" and "website" links are broken
• two stale github clones of OUnit
• one Stack Overflow question
• someone's Facebook page

user102 replied on 2014-10-14 23:55:36:

And you have actually no luck because the broken link are the canonical place to find the documentation in HTML format !!!!

The canonical site:
http://ounit.forge.ocamlcore.org

You'll find the stable place there:
http://ounit.forge.ocamlcore.org/api-ounit/index.html

Actually the page has been demoted from Google because it was 403 (I am using webmaster tool so I have this kind of data).

Give it a few days and it will be back to the top...

I'll try to followup on the other suggestion before closing the bug.

user834 replied on 2014-10-15 07:39:55:

Merci beaucoup. I have taken the liberty to submit a pull request in OPAM for the homepage and doc fields:
ocaml/opam-repository#2872

user102 replied on 2014-10-20 08:45:55:

I think the homepage is now the 2nd link on the search result page, the first being the OPAM page with a link to homepage.

I have contacted other people to make changes as well (e.g. warrenharris has removed its repository) but it will take time to appear in the search result.

I consider this bug closed, but will try to see how to improve all that even more.

This feature request has been migrated from artifact #775 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:37:00.

user102 posted on 2010-10-21 12:08:26:

The env on windows contains a lot of variables and make the output unreadable. We should only display what changed.

user102 replied on 2013-09-30 00:37:00:

Close with OUnit v2.0.0. The display in file logs don't make it more readable, but it is easier to grep.

This feature request has been migrated from artifact #976 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2012-02-22 20:42:53.

user922 posted on 2011-05-26 13:33:06:

As far as I understand, the following function :
val bracket : (unit -> 'a) -> ('a -> 'b) -> ('a -> 'c) -> unit -> 'c
is useful to add a set_up and a tear_down function around a test function.
I think it would be useful to have such a function for a whole test. Something like :
val bracket : (unit -> 'a) -> test -> ('a -> unit) -> unit -> unit
In my case, I want to prepare a complex environment for a large test suite (and close it at the end),
and it really painful to open/close for each test.

Do you think it would be possible to add this feature ?

Thanks.

user102 replied on 2011-05-26 14:19:15:

You should have a look at the function test_decorate which is a generic way to do exactly what you want.

user922 replied on 2011-05-26 14:39:30:

Many thanks for your quick answer, but either I misunderstood the documentation of this function, or it is not really want I want.
I thought that this function changes all the [test_fun] in a test...
But I want my open_env and close_env functions to be called only once... like :

let x = open_env () in
test_fun_1 ();
...
test_fun_n ();
close_env x;

Did I misunderstand [test_decorate] ?

user102 replied on 2011-05-26 15:02:17:

OK, I see what your want.

In fact, the setup/teardown should be individual. This point allow to run a single test, without having to dependencies. I know that this can be cumbersome but setting up a closed environment is a good practice.

If you have a look at oasis-db test suite, you'll see that I start an ocsigen-server foreach tests...

http://darcs.ocamlcore.org/cgi-bin/darcsweb.cgi?r=oasis/oasis-db;a=headblob;f=/test/TestIncoming.ml

(bracket_oasis_db launch the ocsigen webserver).

Most of the time, if you think tests are too small wrt to open_ev/close_ev, you can just create a single test that perform all the asserts.

user922 replied on 2011-05-26 15:07:31:

Ok : it makes sense.
I'll try to organize my tests in a better way.
Thanks for your answers.

This bug has been migrated from artifact #1673 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-09-27 14:05:33.

user102 posted on 2016-09-23 09:59:20:

In the page:
http://ounit.forge.ocamlcore.org/documentation.html

The examples are pointing to the old darcs repository, the links should be updated to point to the real code.

user102 replied on 2019-09-27 14:05:33:

The documentation is now fully contained into the README.md and there is no more reference to darcs into github.com/gildor478/ounit

This bug has been migrated from artifact #1328 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-10-22 19:51:58.

user14438 posted on 2013-10-07 13:11:28:

In my .bashrc I have OCAMLRUNPARAM="b" so that I can get useful stack
traces with ocaml. This interacts poorly with the way OUnit expects
certain tests to be run.

==============================================================================
Failure: OUnit:7:test_case_decorate

OUnit: expected: RFailure("suite_c:1:label", "OUnit: fail");
RFailure("suite_c:0", "OUnit: fail")
but got: RFailure("suite_c:1:label", "OUnit: fail\nRaised at file
"pervasives.ml", line 22, characters 22-33\nCalled from file
"src/oUnit.ml", line 597, characters 6-10\n"); RFailure("suite_c:0",
"OUnit: fail\nRaised at file "pervasives.ml", line 22, characters
22-33\nCalled from file "src/oUnit.ml", line 597, characters
6-10\n")
Raised at file "pervasives.ml", line 22, characters 22-33
Called from file "src/oUnit.ml", line 597, characters 6-10

Ran: 12 tests in: 0.04 seconds.
FAILED: Cases: 12 Tried: 12 Errors: 0 Failures: 1 Skip:0 Todo:0
W: Test 'main' fails: Command
'/home/dbueno/bap-0.7/ounit/_build/test/test.byte' terminated with
error code 1
E: Failure("Tests had a 100.00% failure rate")
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/dbueno/bap-0.7/ounit'
make: *** [all-recursive] Error 1

One way to fix this would be to test that the expected string is a
prefix of the actual string, but, I think ignoring OCAMLRUNPARAM
during build is easier.

Adding

OCAMLRUNPARAM :=

to the top of ounit/Makefile appears to fix the problem without
permanently changing the shell's variables.

user102 replied on 2013-10-22 19:51:58:

Hi, just have tested this and the error doesn't appear in OUnit 2.0.0. In this new version (since a month), we separated stacktrace from the failure message.

I recommend you to upgrade your OUnit version.

Regards
Sylvain

This feature request has been migrated from artifact #1096 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:39:38.

user102 posted on 2012-02-22 21:02:13:

90% of the changes in TESTFLAGS in oasis test suite are restricting tests run to the last one which was failing.

This task can be done automatically by ounit itself:

• run once
• write tests that failed + their timing in a file ounit.state / _build/ounit.state
• let the user fix the test
• read ounit.state
• run tests with the one failing first and the fastest
• allow to run all tests in level + 1 as well (may code this possibilty in >::)
• if one the previous fail, skip the remaining

user11011 replied on 2013-03-02 22:13:31:

Is it really "smart" to focus on only one test ?

True thing, we want our test to pass, obviously. True also that waiting a dozen of seconds before seeing THE test passing or failing is boring. But more than all, we don't want to broke anything !

I suggest that a smart behavior will be to change the sequence and put the failing tests in first.

user102 replied on 2013-09-30 00:39:38:

Close with OUnit v2.0.0. We reorder the test to get the failing one first and skipped the other if still failing.

This bug has been migrated from artifact #1280 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-05-22 08:13:45.

user12332 posted on 2013-05-21 21:46:40:

Hi,

the version menu does not have a 1.1.2 entry in the "Submit New" page in the tracker.

Bye,

Hendrik

This bug has been migrated from artifact #1392 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-08-27 06:50:09.

user16969 posted on 2014-05-13 13:48:35:

Here is a simple example of a failing case in the documented format:

https://gist.github.com/simonjbeaumont/9dbb0771baf616c3493d#file-test-ml

open OUnit

let test1 () = assert_failure "Test failure"

let suite = "suite" >::: ["test1" >:: test1]

let _ =
run_test_tt_main suite

When this fails I expect a non-zero exit code from the executable. This worked in OUnit 1.1.2.

We recently upgraded the OUnit package to 2.0.0 in our environment and found that the exit code for the above is always 0. It correctly reports in the textual output that there is a failure but returns 0.

This silent failure is major for us because any failure won't be picked up by our automated build system.

I can get this to work as desired by opening OUnit2 instead of OUnit and replacing the () parameter of the test1 to _ to match against the test_ctxt type. However, I would need to do this for all of our existing test base.

But we maintain old build environments and we'd like to be able to keep backwards compatibility.

I would have understood this change in behaviour if OUnit2 updates had been made to the OUnit module itself but the separation of the two namespaces implies to me that I should be able to open the OUnit module and expect the same behaviour regardless of whether I have OUnit package version 2.0.0 or 1.x.

user102 replied on 2014-05-13 15:34:18:

The fixe is pretty straightforward (check result and exit with error code), but I encourage you to upgrade to OUnit2.

The reason of the split of interface was that there are some huge changes (i.e. test_ctxt) but the code is a lot more clean than before.... Not even considering the possible improvement of speed you'll get.

I need to do a new release but I have no ETA for that.

This feature request has been migrated from artifact #1230 on forge.ocamlcore.org. It was assigned to user100. It was closed on 2013-02-23 18:34:53.

user8648 posted on 2012-10-28 11:02:58:

In big application it is nice to have unit tests in many files. It would be nice to add some engine to OUnit to provide this functionality. For example

tests/component/component_tests.ml
let test_suite = ....
;;
OUnit.register_test_suite test_suite

test/other_component/other_component_tests.ml
let test_suite = ....
;;
OUnit.register_test_suite test_suite

test/main.ml

OUnit.run_all_registered_test_suites.

Additional comment:

Why the endline character is not printed after "OK" !?
It is a bit irritating when application prints something and forgot to end line.

user102 replied on 2012-10-28 11:37:02:

Most of the time, I use:
tests/component/component_tests.ml
let test_suite = ....
;;

test/other_component/other_component_tests.ml
let test_suite = ....
;;

test/main.ml

OUnit.run_test_tt_main ["foo" >:::
[Component_tests.test_suite;
Other_component_tests.test_suite]]

I think this is exactly what you need. May I close the bug ?

The EOL with OK is an issue that will be fixed in 2.0.0

user8648 replied on 2012-10-28 11:51:59:

I would be more happy with auto-collecting of tests from files.

On the other hand maybe my request is the wrong way in Ocaml. I rely on side effects, but some tools, like ocamlbuild, does not link with files which are not used. So maybe it is dangerous to rely on "let _ = ...." for collecting tests.

OK, you can close.

Thanks.

This patch has been migrated from artifact #1766 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-09-19 21:05:07.

user320 posted on 2019-04-04 11:19:03:

This happened to me when doing this:

OCAMLPARAM=_,runtime-variant=d opam install --with-tests x509.0.6.2

After running some tests, the test runner loops while displaying a line every second in its log:
2019-04-04T09:19:22+00:00 Macabane.local#00 I: 0 tests running: .

What happens is that the test triggers a failed assertion in the runtime, in a finalization function. This happens, on the last test, after the worker has already reported that the test passed but before it has answered the Exit message from the master. Then the master loops, waiting for an answer from a dead process.

The attached patch is only a partial fix: if the finalisation function loops instead of crashing the process, it will not be detected. I don't understand the code well enough to add a timeout for this case.

user102 replied on 2019-08-29 21:58:20:

I have tried to reproduce your error, but I am not sure to understand what I need to do.

Here is what I have done:
https://github.com/gildor478/ounit/blob/bug1766/test/testFakeShared.ml

I have created a whole new branch just to test this bug, can you tell me how to reproduce this bug?

user102 replied on 2019-09-19 21:05:07:

I have worked more on this issue and found a way to reproduce it and found a solution:

• Run a Gc.full_compact before declaring the test succesful. This helps to catch bugs with the finaliser throwing exceptions.

gildor478/ounit@624337a

• Actually tests if idle_workers are still running.

gildor478/ounit@c9fbb51

The second change is quite hard to test, because it needs to trigger an exception outside of a normal test (and the first change now prevents to have such a function).

I think this should be enough to fix the problem.

This bug has been migrated from artifact #1119 on forge.ocamlcore.org. It was assigned to user100. It was closed on 2013-09-30 00:36:09.

user5510 posted on 2012-03-20 01:51:05:

The "configure" script should have the execution bit enabled

user102 replied on 2013-09-30 00:36:09:

Close with OUnit v2.0.0.

This bug has been migrated from artifact #1761 on forge.ocamlcore.org. It was assigned to user100. It was closed on 2019-08-27 06:45:02.

user297 posted on 2017-09-29 13:54:56:

See ocaml/opam-repository#10364 for a patch

user297 replied on 2017-09-29 13:55:48:

Duplicate of 1760.

This bug has been migrated from artifact #1381 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-08-27 06:49:24.

user1231 posted on 2014-03-23 14:26:27:

It seems that cmp_float can't handle infinities properly. Example:

cmp_float neg_infinity neg_infinity;;

• : bool = false # cmp_float infinity infinity;;
• : bool = false

This feature request has been migrated from artifact #640 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2010-10-05 12:58:40.

user102 posted on 2010-05-25 10:39:53:

For example extra Arg.String et al

This feature request has been migrated from artifact #1261 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:40:36.

user11011 posted on 2013-03-02 23:11:27:

Asserts are fatals, that is, if we put multiple asserts that fails in one test, the runner stops at the first failing assert.

However, when a test fails, don't we want all possible information ?

Nowadays, the workaround is to split our test in multiples assertions, and that's a good thing to promote shorts and readable tests.
The sad thing is, it's not always very clever ie for one pure functional action, if we want to have multiple asserts and multiple outputs in case of failure, we duplicate the code and change only the assert. That's bad.

My request is to add non-failure asserts, as Google Tests do with their EXPECT_* tests. ( http://code.google.com/p/googletest/wiki/Primer#Assertions )

Theses tests act as normal asserts in all ways but :

• If they fails, the runner continue to eval the other asserts
• If at least one 'expect_' fail, the test is failed
• If we meet an assert that fails, we obviously don't go ahead even if there are only 'expect_' on our way

From an implementation point of view, this implies that Exceptions can't be used anymore.
A simple way would be to initialize a global state in OUnitCore.perform_test. That's not shocking but it's disappointing to going out of the functional paradigm only for that.

An other way would be to separate the action we want to test and the post-conditions it have to meet. It's far more flexible from the runner point of view but implies that 1) we'll broke the existing paradigm of OUnit and 2) we can't put expects in the middle of an action.

I like the second method. It's the way I use to write tests, but that's only how I see things.

user102 replied on 2013-03-03 19:58:04:

Works for me but only for OUnit 2.

I plan to provide a "state" parameter to test functions that should be used to log and will also allow to do this kind of non-fatal assertion.

user102 replied on 2013-09-30 00:40:36:

Close with OUnit v2.0.0.

This feature request has been migrated from artifact #920 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2012-02-22 20:42:03.

user855 posted on 2011-02-26 15:14:36:

No quite a feature request.

Would like to ask if it is possible to update the GOD package to the latest and greatest version of OUnit.

TIA

user102 replied on 2011-02-26 15:35:06:

Indeed, I should have the courage to commit the attached file to GODI. Maybe you can try it (if you know better GODI than I).

user922 replied on 2011-05-24 13:59:09:

It would be great indeed to have the last version of oUnit in GODI. I am beginning to use it and it looks very nice ! so I am a bit frustrated not to have some of the documented features...
Anyway, many thanks for that tool !

This patch has been migrated from artifact #639 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2010-06-22 11:57:17.

user102 posted on 2010-05-25 10:38:57:

Attached is a patch for oUnit which does the following:

• Augments RError and RFailure with an additional string option element
  to store a backtrace.
• Adds code to test runner to store the backtrace in the result if
  backtraces are enabled.
• Adds code to reporting to print backtraces with the error/failure
  report.
• Modifies the Makefile to compile everything with -g (so stack traces
  don't get lost in oUnit).

From Michael Ekstrand

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528603

This bug has been migrated from artifact #636 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2010-10-05 12:58:07.

user102 posted on 2010-05-25 10:31:12:

The bracket example should be a piece of code.

There is a * in the skip_if function.

This patch has been migrated from artifact #1422 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2017-10-01 22:16:31.

user320 posted on 2014-09-04 06:17:55:

There are some format strings that are "invalid" in the ounit 2.0.0 sources.

In general, invalid formats are nonsensical format strings that were accepted in OCaml 4.01.0 and earlier, but whose semantics is unspecified. They are still accepted by the new Printf implementation of OCaml 4.02.0 but in some cases with different semantics, and they will be statically rejected by OCaml 4.03.0.

You can check for them in OCaml 4.02.0 with the flag -strict-formats.

In the case of ounit, I think the behavior has not changed between 4.01.0 and 4.02.0. The only kind of invalid format is "%0.3f". This is considered invalid beause it specifies a padding character (with the flag 0), but no minimum field width (no number before the dot) so there will never be padding.

user102 replied on 2019-09-17 09:49:51:

Fixed with:
gildor478/ounit@73ec697

This bug has been migrated from artifact #1760 on forge.ocamlcore.org. It was assigned to user100. It was closed on 2019-08-27 06:52:25.

user7847 posted on 2017-09-23 16:23:36:

Same as: https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=1759&group_id=244&atid=1098

user297 replied on 2017-09-30 13:26:09:

There's a patch here: ocaml/opam-repository#10364

This feature request has been migrated from artifact #1149 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:40:16.

user102 posted on 2012-05-08 19:35:08:

It should be possible to chdir when running a command.

Sys.chdir change the environment of the application and it should have bad interaction with the running processes (esp. if running parallel).

user102 replied on 2013-09-30 00:40:16:

Close with OUnit v2.0.0.

This bug has been migrated from artifact #1279 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-05-22 08:10:23.

user12332 posted on 2013-05-21 21:44:14:

Hi,

ounit 1.1.2 installs oUnit.cmx and oUnitDiff.cmx, which were not
installed in version 1.1.1. Is this really necessary? IMHO they
should not get installed.

Bye,

Hendrik Tews

user102 replied on 2013-05-22 08:10:23:

Yes it is bettet to have them because it triggers certain optimization when compiling with ocamlopt.

user12332 replied on 2013-05-22 09:09:07:

OK, I forgot about that...

H.

This bug has been migrated from artifact #870 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2012-01-18 21:15:23.

user825 posted on 2011-01-09 05:44:15:

The example at examples/example.ml calls function was_successful that was exported by the oUnit module interface in version 1.0.3, but is not longer exported in version 1.1.0.

This bug has been migrated from artifact #1404 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2019-08-27 06:54:29.

user919 posted on 2014-06-21 15:08:51:

darcs get http://darcs.ocamlcore.org/repos/ounit/ounit

should be,

darcs get http://darcs.ocamlcore.org/repos/ounit ounit

user102 replied on 2019-08-27 06:54:29:

Not using darcs anymore.

The new URL to get ounit can be found there:
https://github.com/gildor478/ounit

This feature request has been migrated from artifact #1095 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:38:23.

user102 posted on 2012-02-22 20:57:03:

It should be useful to be able to run several tests in parallel.

This can be done in different ways:

• OUnitMT: multi-threaded run_test_main_tt, start multiple tests using thread (useful when running external commands that can be preempted)
• OUnitMP: multi-process run_test_main_tt, start multiple processes, useful when running tests that cannot be-preempted

user102 replied on 2013-09-30 00:38:23:

Close with OUnit v2.0.0.

This bug has been migrated from artifact #1270 on forge.ocamlcore.org. It was assigned to user102. It was closed on 2013-09-30 00:35:57.

user11010 posted on 2013-04-01 18:09:42:

Hi,

Currently OUnit does not show a newline after running the testcases successfully, so the shell looks weird. OTOH, it does display a final newline when displaying options like --help, so I can't just add a newline in my own program, because that would display two newlines.

regards,
Marek

user102 replied on 2013-04-01 19:18:13:

Already fixed in 2.0.0

user11010 replied on 2013-04-01 19:24:21:

Thanks, and sorry for the useless report, I was only trying 1.1.2. Looking forward to 2.0.0!

user102 replied on 2013-09-30 00:35:57:

Close with OUnit v2.0.0.