Menu
▾
▴
ocaml-lib-devel
|
From: Brian H. <bri...@ql...> - 2003-05-30 21:16:01
|
I think it would be a good idea to add unit tests to all the library functions using OUnit: http://home.wanadoo.nl/maas/ocaml/ I think unit tests are *less* necessary in Ocaml due to our wonderful type system, but they're still a good idea. Brian |
|
From: Nicolas C. <war...@fr...> - 2003-06-02 03:09:28
|
> I think it would be a good idea to add unit tests to all the library > functions using OUnit: > http://home.wanadoo.nl/maas/ocaml/ > > I think unit tests are *less* necessary in Ocaml due to our wonderful type > system, but they're still a good idea. I agree, but I'm not familiar enough with others langages Unit tests library to see if this implementation is a convenient way of doing unit tests. Maybe we could write a library mixing unit and benchmarks tests ? ( something similar to Doug Bagley's one ). Theses two should stick well together. Nicolas Cannasse |
|
From: Brian H. <bri...@ql...> - 2003-06-02 22:24:11
|
On Mon, 2 Jun 2003, Nicolas Cannasse wrote: > > I think it would be a good idea to add unit tests to all the library > > functions using OUnit: > > http://home.wanadoo.nl/maas/ocaml/ > > > > I think unit tests are *less* necessary in Ocaml due to our wonderful type > > system, but they're still a good idea. > > I agree, but I'm not familiar enough with others langages Unit tests library > to see if this implementation is a convenient way of doing unit tests. Maybe > we could write a library mixing unit and benchmarks tests ? ( something > similar to Doug Bagley's one ). Theses two should stick well together. > My preference would be to be able to compile the library *without* the unit testing code in it. This will require some thought, and probably some makefile hacking. Brian |
|
From: Nicolas C. <war...@fr...> - 2003-06-04 02:48:41
|
> > > I think it would be a good idea to add unit tests to all the library > > > functions using OUnit: > > > http://home.wanadoo.nl/maas/ocaml/ > > > > > > I think unit tests are *less* necessary in Ocaml due to our wonderful type > > > system, but they're still a good idea. > > > > I agree, but I'm not familiar enough with others langages Unit tests library > > to see if this implementation is a convenient way of doing unit tests. Maybe > > we could write a library mixing unit and benchmarks tests ? ( something > > similar to Doug Bagley's one ). Theses two should stick well together. > > > > My preference would be to be able to compile the library *without* the > unit testing code in it. This will require some thought, and probably > some makefile hacking. Why Brian ? I mean, having a big ExtLib.cma is not a problem, since we're using different modules, the ocaml linker will find itself which ones to choose. Of course, you also need the CMIs since there is currently no way of packaging several CMIs. But compilation speed shouldn't be a problem. BTW, I'm planning to add soon XmlLight to the ExtLib , and I think the best is to link XmlLight modules with others, even if we have separate compilation. About compilation and makefiles issues, I'm also planning to add some options to ocamake so you can write some kind of Ocamakefile and you don't need make any more (with all the problems of calling RM or DEL for cleaning, / against \ in paths , and so on...). Then the ExtLib will be simply compiled (installed ?) by running "ocamake" in its directory. Nicolas Cannasse |
|
From: Mikhail F. <mi...@ki...> - 2003-06-04 05:43:16
|
Hi! > > My preference would be to be able to compile the > > library *without* the unit testing code in it. > > This will require some thought, and probably > > some makefile hacking. > > Why Brian ? > I mean, having a big ExtLib.cma is not a problem, since > we're using different modules, Unit testing code is usually implemented as a seperate program which uses the library, not as part of the library. Mikhail |
|
From: Nicolas C. <war...@fr...> - 2003-06-04 05:56:06
|
> > > My preference would be to be able to compile the > > > library *without* the unit testing code in it. > > > This will require some thought, and probably > > > some makefile hacking. > > > > Why Brian ? > > I mean, having a big ExtLib.cma is not a problem, since > > we're using different modules, > > Unit testing code is usually implemented as a seperate > program which uses the library, not as part of the library. Mea Culpa ! I really misunderstood the topic of this thread :) I was thinking that we could add an "Unit test library" to the ExtLib, which would of course be compiled with it. As for "writing unit tests for ExtLib" , if someone have enough will to so so, then why not... but I don't see myself covering all Enum cases that can occur with unit tests :-) I think we can make releases/bugfix enough often to wait for the users to find bugs. Nicolas Cannasse |
|
From: Brian H. <bh...@sp...> - 2003-06-04 19:12:08
|
On Wed, 4 Jun 2003, Mikhail Fedotov wrote: > Hi! > > > > My preference would be to be able to compile the > > > library *without* the unit testing code in it. > > > This will require some thought, and probably > > > some makefile hacking. > > > > Why Brian ? > > I mean, having a big ExtLib.cma is not a problem, since > > we're using different modules, > > Unit testing code is usually implemented as a seperate > program which uses the library, not as part of the library. > This actually limits the ability of the unit testing to nail down what just broke. For example, the PSQueue module has internal functions "rotate_right" and "rotate_left". I'd like the unit tests to test those functions independently- and balance as seperate from rotate. Allowing me to tell if I broke insert, balance, or a rotate. My inclination is to agree with Nicolas and just toss the test functions into the library and worry about size when it becomes a problem. Brian |
|
From: Mikhail F. <mi...@ki...> - 2003-06-04 21:00:07
|
Hi! > > > > My preference would be to be able to compile the > > > > library *without* the unit testing code in it. > > > > This will require some thought, and probably > > > > some makefile hacking. > > > > > > Why Brian ? > > > I mean, having a big ExtLib.cma is not a problem, > since > > > we're using different modules, > > > > Unit testing code is usually implemented as a seperate > > program which uses the library, not as part of the > library. > > > > This actually limits the ability of the unit testing to > nail down what > just broke. For example, the PSQueue module has internal > functions > "rotate_right" and "rotate_left". I'd like the unit > tests to test those > functions independently- and balance as seperate from > rotate. Allowing me > to tell if I broke insert, balance, or a rotate. > > My inclination is to agree with Nicolas and just toss the > test functions > into the library and worry about size when it becomes a > problem. This won't be unit testing in the usual sense then. Unit testing covers external interface of the library; the main point is to figure out that something is broken; as long as it is known, it is easy to find exact error line, even by putting "let () = print_string error_here in" in the code. Including tests for internal functions does not buy much but makes the whole thing more complex. This kind of testing is usually implemented by inserting asserts in C code and by raising Invalid_argument in some ocaml functions. If you really need to test internal function I think (with my limited ocaml expirience) that it is possible to compile a special version of the library by copying library.ml to testlibrary.ml and creating the specil version of the library out of it which would include all the functions. I don't remember if .mli file is strictly required (I've never tried to build a library without it), but if it is not, then it is even easier. Mikhail |
|
From: Brian H. <bh...@sp...> - 2003-06-04 22:02:57
|
On Thu, 5 Jun 2003, Mikhail Fedotov wrote: > Hi! > > This won't be unit testing in the usual sense then. Unit > testing covers external interface of the library; the main > point is to figure out that something is broken; as long as > it is known, it is easy to find exact error line, even by > putting "let () = print_string error_here in" in the code. > > Including tests for internal functions does not buy much > but makes the whole thing more complex. This kind of > testing is usually implemented by inserting asserts in C > code and by raising Invalid_argument in some ocaml > functions. My general experience has been that the smaller the hunk of code you test, the more likely you are to find problems and the easier it is to get full coverage (all possible conditions are tested). Yes, this makes things more complex. What I want is classic C conditional compilation. I want to be able to do "make test" which builds a copy of the libraries with unit testing enabled, and runs the unit tests. "make" would then build copies of the library sans the unit test code for "production". Asserts get used *in addition to* strong type checking and unit tests. And stay in the final "production" code. Yes, this is way overkill. As the guy said when asked what do with his mother-in-law's mortal remains, "embalm, cremate, then bury. Take no chances." > > If you really need to test internal function I think (with > my limited ocaml expirience) that it is possible to compile > a special version of the library by copying library.ml to > testlibrary.ml and creating the specil version of the > library out of it which would include all the functions. I > don't remember if .mli file is strictly required (I've > never tried to build a library without it), but if it is > not, then it is even easier. > This is what I was talking about when I mentioned "makefile hacks". Unfortunately, I know enough about the build environment of Windows (despite several years busily repressing memories) that I am wary of doing and scripting hacks. The only scripting language I am sure exists is Ocaml. Hmm. That might be enough. All I need to do is: - move the original code foo.ml to a backup file. - concatenate the original code and the unit test code into the new foo.ml - do the same with foo.mli - Compile foo.ml[i] - run the unit tests - delete the new foo.ml[i] - move the originals back Brian |
|
From: Nicolas C. <war...@fr...> - 2003-06-05 02:10:09
|
[...]
> Asserts get used *in addition to* strong type checking and unit tests.
> And stay in the final "production" code. Yes, this is way overkill. As
> the guy said when asked what do with his mother-in-law's mortal remains,
> "embalm, cremate, then bury. Take no chances."
There is a flag in ocamlc that does what you want :
-noassert : Don't compile assertion checks.
That way you may have a "debug" version and "release" version of the
library.
Note that the "assert false" are not removed, because they're handled as
special cases.
Nicolas Cannasse
|
|
From: MikhailFedotov <mi...@ki...> - 2003-06-05 07:08:56
|
Hi! > This is what I was talking about when I mentioned "makefile hacks". > Unfortunately, I know enough about the build environment of Windows > (despite several years busily repressing memories) that I am > wary of doing and scripting hacks. The only scripting language I am > sure exists is Ocaml. > > Hmm. That might be enough. All I need to do is: > > - move the original code foo.ml to a backup file. > > - concatenate the original code and the unit test code into > the new foo.ml I thought that the only problem is that internal functions are not present in the external interface, and can be solved by extending external inteface to include everything for the test version of the library. This way you'll end up with "testing the library", not just the code, as well as library compiling process, etc. More clean approach, without unwanted surprises. Mikhail |
|
From: John M. S. <sk...@oz...> - 2003-06-08 15:28:21
|
Brian Hurt wrote: > This is what I was talking about when I mentioned "makefile hacks". > Unfortunately, I know enough about the build environment of Windows > (despite several years busily repressing memories) that I am wary of doing > and scripting hacks. The only scripting language I am sure exists is > Ocaml. Then use it. Only, please get rid of primary makefiles. Make is a very stupid, ugly, unworkable tool. Its use should be avoided at all costs. It offers only one advantage: familiarity for uses to say make to build something. I don't know if this can be done but a simple makefile: all: ocaml xlmake <arguments> which simply invokes the ocaml program xlmake with the arguments to the command make, would even solve that problem. Otherwise I'm happy to read the doce enough to learn I have to type xlmake or ocaml xlmake.ml to do a make. You may note that to do this efficiently would require some kind of topological dependency sorting: well, ExtLib has a data structure for that doesn't it? :-) -- John Max Skaller, mailto:sk...@oz... snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X