From: Bardur A. <oca...@sc...> - 2004-12-18 00:30:29
|
On Sat, Dec 18, 2004 at 11:16:53AM +1100, skaller wrote: > On Sat, 2004-12-18 at 00:40, Bardur Arantsson wrote: > > > I think we may be discussing different things... I'm only > > talking about something which ExtLib developers can use > > exclusively for testing ExtLib itself, not about making a > > test harness available to ExtLib users. > > No, we're talking about the same thing. > > > In general, yes, but it doesn't mean that we can't agree > > on an *internal* method for testing ExtLib itself. > > Well, can you could write a specification? > > Assume a directory containing tests, people can dump > tests in it. The tests need names -- what names? > it must be possible to specify expected result, > the harness must report which test(s) (if any) fail. > > You can use an 'assert' test (if the code runs at > all it passes). The problem with that is that > library function are hard to test like that.. > > How do you test 'string.split'? This is not so easy! > Try: > > assert (x = combine "/" (split x "/")) > > Which suggests making the split char vary. Uh, and...? If you want to try different splitter characters, just do let l = [ ("/", "a/b", ["a";"b"]); ("/", "a/b/c", ["a";"b"]); ("#", "a#b", ...) ] in List.map (fun sep str exp_values -> assert (exp_values = split sep str)); List.map (fun sep str exp_values -> assert (str = combine sep exp_values)) in your test code. This also buys separate tests for split and combine (and thus tests more than whether the two are "inverses" of each other). If you want more flexibility you can always generate the l list as a cartesian product of separators and field values/strings. I think you may be overdesigning/overthinking this... > How do you test ExtSet? You need stuff to put in it, > where does it come from? Same idea as above, you just hardcode the test data into your test_*.ml files... -- Bardur Arantsson <ba...@im...> <ba...@sc...> A morning without coffee is like something without something else. |