I want to change the SmartPtr test project to use a unit testing library instead of just assert macros. Assertions only work in debug builds, and do not provide the type of output I want.
I wrote that unit test project myself because other unit test mechanism did not provide the capabilities I wanted, or did not have the robustness I required.
Please let me know your thoughts on this matter.
Sincerely,
Rich
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unit tests and non regression tests are vital to a library such as Loki and I do agree to standardize our testing code. For the moment, every developer has written its own unit test and the result is quite heterogeneous.
However, as a programmer, I know how frustrating it is to have to include libraries when the only thing you want is just have a look at some functionnalities. If I was new to Loki, I think I'd prefer the current version against a more "beautifully tested version" because you just have to download and start coding. If Loki depends on other library, I think it could prevent people from trying (and adopting : ) Loki.
What I suggest to overcome this problem is to split the downloads in two parts :
+ The standalone Loki library with no tests and no dependencies
+ A testing package that provides unit & non regressions tests standardized via a testing framework ( possibly depending on an external library).
Regarding the library you proposes (CppUnitTest), it seems quite lightweight which is a good point but I haven't tested it. Nevertheless I tested Boost Unit Test Framework ( http://www.boost.org/libs/test/doc/components/utf/index.html ) and I think it actually is pretty good. For instance, it is better and easier to use than CppUnit ( the counter part of JUnit : the well known unit testing framework for Java ).
Well, here are my opinions. As usual : feedback is welcome : )
Guillaume
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a new testing strategy would be great! We really need more testing code.
Your test project looks very nice, and because of its very limited
size I think we could just add the two files to Loki.
Then we could still release a complete Loki package without any other dependencies.
What about renaming the current "test" folder into "examples" (very simple
with subversion) and then creating "tests" where we add all new unit tests?
And were should we add your unit test code files? In "tests" or should we make
it a part of Loki? I think for the beginning the best would be to add the
unit test files some were below "tests" and then we will see, if it later
becomes "Loki's Unit Test" (wasn't a Loki credo "Small is beautiful"?)
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be great to have a example folder as well as a test one.
Well commented code snippet are clearly the best documentation we could provide for Loki, it's a great idea.
I also agree with the folder layout you proposes (and the possibility to include CppUnitTest into Loki, either as part of the library or as a test helper).
I would also like to point out two other major remarks :
+ We need a more complete documentation to provide an overview of the concepts ( I already tried to write a few pages here : http://www.barbare.kicks-ass.net/mediawiki/index.php/Loki_HOW-TOs - it's under construction but it illustrates what I mean with "overview of the concepts").
+ We need a more flexible compilation scheme to build the different kind of library (Debug/Release - static/dynamic - single/multithreaded ...)
Those two points have already been discussed a bit ( sometimes in private ) but I think they should be discussed publicly so I will open threads if you mind.
Sincerely,
Guillaume
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I looked at the Loki-How-To pages. I like these so far. Eventually, I would like to see How-To pages for all the major parts of Loki. We have needed something like for a while. My vision for these is to have them on the Loki main page: http://loki-lib.sourceforge.net/ - or at least linked from there.
Thanks!
Rich
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think we shall soon need to change the test folder - and move some of the projects in there into an example folder.
Before we decide whether we want to add CppUnitTest to Loki, I would like to mention some future changes I want to make to CppUnitTest.
1. I want to replace the calls to _snprintf with something more portable.
2. I want to add thread-safety to it, but I also want to keep it simple for single-threaded applications.
3. I want to make an XML outputter.
4. I may want to add a different Create function which configures the singleton based upon the contents of an .ini file.
Each of these changes will make CppUnitTest bigger. If that happens, I may split the single .cpp file into several smaller files.
Cheers,
Rich
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think Loki::SPrintf is due for a rewrite. Each call to the I/O primitives locks the stream, and therefore SPrintf locks the stream several times in one call and as such is slow and thread-unsafe.
The problem is that implementation cannot be portable; each C library implementation defines its own extensions to address this problem. For example, gnu defines flockfile, fputc_unlocked, funlockfile etc. for properly locked output. Loki::SPrintf should use those.
Then, we need to also define Loki::Scanf with enough extensions to make it actually useable. :o)
Andrei
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I seriously thought about using Loki::SPrintf, but decided against it. For me, the deciding factor was: "What if I want to use the unit test mechanism to test Loki::SPrintf?" I don't want the unit test mechanism to depend on anything inside Loki if it has to test Loki.
Cheers,
Rich
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Before making my own unit test project, I looked at Boost's and tried it. Boost's does not provide all the output information I wanted - or if it does, I did not discover how. I wanted stats on how many tests were done, how many passed, etc... so I could track these stats while the code changed.
Perhaps that time has come to make two downloads for Loki. One download could contain just the library and a few examples and with no external dependencies. Another download could contain everything needed by Loki contributors and people who wish to extend Loki on their own. Before we make that decision, I would want to hear from most regular Loki contributors and many users.
You're right about how each developer has written his own tests for each project and the result is a heterogeneous mix. That's partly due to test projects having different purposes.
1: some demonstrate that parts of Loki can compile on different machines,
2: some projects serve as examples on how to use Loki, and
3: some act as run time tests for parts of Loki.
My intentions are aimed at the third set of projects. I hope that by introducing a test project, at least those will have a consistent testing mechanism.
Cheers,
Rich
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Everyone,
I want to change the SmartPtr test project to use a unit testing library instead of just assert macros. Assertions only work in debug builds, and do not provide the type of output I want.
I intend to use the C++ Unit Test project located at: http://sourceforge.net/projects/cppunittest/
I wrote that unit test project myself because other unit test mechanism did not provide the capabilities I wanted, or did not have the robustness I required.
Please let me know your thoughts on this matter.
Sincerely,
Rich
Hi Richard,
Unit tests and non regression tests are vital to a library such as Loki and I do agree to standardize our testing code. For the moment, every developer has written its own unit test and the result is quite heterogeneous.
However, as a programmer, I know how frustrating it is to have to include libraries when the only thing you want is just have a look at some functionnalities. If I was new to Loki, I think I'd prefer the current version against a more "beautifully tested version" because you just have to download and start coding. If Loki depends on other library, I think it could prevent people from trying (and adopting : ) Loki.
What I suggest to overcome this problem is to split the downloads in two parts :
+ The standalone Loki library with no tests and no dependencies
+ A testing package that provides unit & non regressions tests standardized via a testing framework ( possibly depending on an external library).
Regarding the library you proposes (CppUnitTest), it seems quite lightweight which is a good point but I haven't tested it. Nevertheless I tested Boost Unit Test Framework ( http://www.boost.org/libs/test/doc/components/utf/index.html ) and I think it actually is pretty good. For instance, it is better and easier to use than CppUnit ( the counter part of JUnit : the well known unit testing framework for Java ).
Well, here are my opinions. As usual : feedback is welcome : )
Guillaume
Hi Rich,
a new testing strategy would be great! We really need more testing code.
Your test project looks very nice, and because of its very limited
size I think we could just add the two files to Loki.
Then we could still release a complete Loki package without any other dependencies.
What about renaming the current "test" folder into "examples" (very simple
with subversion) and then creating "tests" where we add all new unit tests?
And were should we add your unit test code files? In "tests" or should we make
it a part of Loki? I think for the beginning the best would be to add the
unit test files some were below "tests" and then we will see, if it later
becomes "Loki's Unit Test" (wasn't a Loki credo "Small is beautiful"?)
Peter
I completely agree with you Peter.
It would be great to have a example folder as well as a test one.
Well commented code snippet are clearly the best documentation we could provide for Loki, it's a great idea.
I also agree with the folder layout you proposes (and the possibility to include CppUnitTest into Loki, either as part of the library or as a test helper).
I would also like to point out two other major remarks :
+ We need a more complete documentation to provide an overview of the concepts ( I already tried to write a few pages here : http://www.barbare.kicks-ass.net/mediawiki/index.php/Loki_HOW-TOs - it's under construction but it illustrates what I mean with "overview of the concepts").
+ We need a more flexible compilation scheme to build the different kind of library (Debug/Release - static/dynamic - single/multithreaded ...)
Those two points have already been discussed a bit ( sometimes in private ) but I think they should be discussed publicly so I will open threads if you mind.
Sincerely,
Guillaume
Hi Guillaume,
I looked at the Loki-How-To pages. I like these so far. Eventually, I would like to see How-To pages for all the major parts of Loki. We have needed something like for a while. My vision for these is to have them on the Loki main page: http://loki-lib.sourceforge.net/ - or at least linked from there.
Thanks!
Rich
Hi Peter,
I think we shall soon need to change the test folder - and move some of the projects in there into an example folder.
Before we decide whether we want to add CppUnitTest to Loki, I would like to mention some future changes I want to make to CppUnitTest.
1. I want to replace the calls to _snprintf with something more portable.
2. I want to add thread-safety to it, but I also want to keep it simple for single-threaded applications.
3. I want to make an XML outputter.
4. I may want to add a different Create function which configures the singleton based upon the contents of an .ini file.
Each of these changes will make CppUnitTest bigger. If that happens, I may split the single .cpp file into several smaller files.
Cheers,
Rich
> 1. I want to replace the calls to _snprintf with something more portable.
What about using Loki::SPrintf? (examples/SafeFormat)
I think Loki::SPrintf is due for a rewrite. Each call to the I/O primitives locks the stream, and therefore SPrintf locks the stream several times in one call and as such is slow and thread-unsafe.
The problem is that implementation cannot be portable; each C library implementation defines its own extensions to address this problem. For example, gnu defines flockfile, fputc_unlocked, funlockfile etc. for properly locked output. Loki::SPrintf should use those.
Then, we need to also define Loki::Scanf with enough extensions to make it actually useable. :o)
Andrei
I seriously thought about using Loki::SPrintf, but decided against it. For me, the deciding factor was: "What if I want to use the unit test mechanism to test Loki::SPrintf?" I don't want the unit test mechanism to depend on anything inside Loki if it has to test Loki.
Cheers,
Rich
"What if I want to use the unit test mechanism to test Loki::SPrintf?"
This makes sense.
Peter
Hi Guillaume,
Before making my own unit test project, I looked at Boost's and tried it. Boost's does not provide all the output information I wanted - or if it does, I did not discover how. I wanted stats on how many tests were done, how many passed, etc... so I could track these stats while the code changed.
Perhaps that time has come to make two downloads for Loki. One download could contain just the library and a few examples and with no external dependencies. Another download could contain everything needed by Loki contributors and people who wish to extend Loki on their own. Before we make that decision, I would want to hear from most regular Loki contributors and many users.
You're right about how each developer has written his own tests for each project and the result is a heterogeneous mix. That's partly due to test projects having different purposes.
1: some demonstrate that parts of Loki can compile on different machines,
2: some projects serve as examples on how to use Loki, and
3: some act as run time tests for parts of Loki.
My intentions are aimed at the third set of projects. I hope that by introducing a test project, at least those will have a consistent testing mechanism.
Cheers,
Rich