artifact_id;status_id;status_name;priority;submitter_id;submitter_name;assigned_to_id;assigned_to_name;open_date;close_date;last_modified_date;summary;details;"Component";"Operating System";"Product"
771;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2010-10-06 22:03";"";"2010-10-06 22:03";"Add wildcard to -only-test";"The path as defined by OUnit contains number that can change if more tests get added. To be able to run the same test through different version, we should add a wildcard to allow matching any number:

OASIS:3:FileTemplate:2:filetemplate3.txt  -> OASIS:*:FileTemplate:*:filetemplate3.txt

It is especially useful when running ""darcs trackdown"".";"General";"None";"ounit"
775;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2010-10-21 12:08";"";"2010-10-21 12:08";"Don't display full env in assert_command";"The env on windows contains a lot of variables and make the output unreadable. We should only display what changed.";"General";"None";"ounit"
862;1;"Open";3;824;"Török Edwin";102;"Sylvain Le Gall";"2011-01-04 13:08";"";"2011-01-14 14:44";"ounit: support timeouts and running tests in separate process";"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;";"General";"All";"ounit"
874;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2011-01-14 14:46";"";"2011-01-14 14:46";"bracket_tmpdir";"Just as OUnit.bracket_tmpfile, a function should create a temporary directory.";"General";"All";"ounit"
1095;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2012-02-22 20:57";"";"2012-02-22 20:57";"Run in parallel";"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";"General";"None";"ounit"
1096;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2012-02-22 21:02";"";"2013-03-02 22:13";"Be smart when running tests";"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
";"General";"None";"ounit"
1097;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2012-02-22 21:04";"";"2012-02-22 21:04";"Run only tests for which the code has changed";"It should be great to be able to run only the tests that matter for the code we are working on. 

Typically, if you modify A.ml you want to run the tests that depends on A.ml and not the one that depends on B.ml which is untouched.

";"General";"None";"ounit"
1098;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2012-02-22 21:43";"";"2012-09-05 03:57";"TAP support";"It should be great to support TAP:
http://testanything.org";"General";"None";"ounit"
1099;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2012-02-22 21:49";"";"2012-02-22 21:49";"Be vim/quickfix friendly";"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.";"General";"None";"ounit"
1109;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2012-03-07 23:12";"";"2012-03-07 23:12";"Verbose in ounit.log and redirect vim/quickfix to that";"Don't display the verbose output but store it in a file. So that you don't have to run it twice.";"General";"None";"ounit"
1149;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2012-05-08 19:35";"";"2012-05-08 19:35";"asssert_command and chdir";"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).";"General";"None";"ounit"
1150;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2012-05-09 23:03";"";"2012-09-05 03:57";"add ~env_export to assert_command";"Something that allow to really export like in standard sh:

       let env_export nm vl env =
         let replaced = ref false in
           for i = 0 to Array.length env - 1 do
             if OASISString.starts_with ~what:(nm^""="") env.(i) then
               begin
                 env.(i) <- nm^""=""^vl;
                 replaced := true
               end
           done;
           if not !replaced then
             Array.append env [|nm^""=""^vl|]
           else
             env
       in";"None";"None";"None"
1151;1;"Open";3;102;"Sylvain Le Gall";102;"Sylvain Le Gall";"2012-05-09 23:32";"";"2012-09-05 03:57";"Capture stderr of assert_command";"Stderr is most of the time more useful than stdout when failing.";"None";"None";"None"
1261;1;"Open";3;11011;"Thomas Wickham";102;"Sylvain Le Gall";"2013-03-02 23:11";"";"2013-03-03 19:58";"Adding non-fatal assertions";"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.
";"General";"All";"ounit"
1276;1;"Open";3;4175;"Francois Berenger";102;"Sylvain Le Gall";"2013-05-14 06:45";"";"2013-05-15 00:47";"color output of running a test suite";"Hello,

It may help to have green on terminals that support
it when running a test suite (for tests that pass).

If some things fail, they should be in red.

Thanks,
F.
";"General";"Linux";"ounit"