From: Karol L. <kar...@kn...> - 2007-09-03 23:23:45
|
I think it is a good idea to also clean up the unittests a bit before releasing 0.8. In the interest of this, I added a "SKIPPED" column in the test summary and the appropriate code for monitoring this (currently based on PASS being in the docstring). This way it easier to see where we are skipping unittests. Also, in my last commit I merged testmodule into testall as Noel suggested (although the name 'testall' does not reflect its function anymore!). Other issues that you might want to comment on: 1) there should be more coverage of unittests for methods(?) 2) should unittests for parsers and methods be either better integrated (possibly run through the same function) or better separated (in separate directories)? Presently, testall.py runs only parser unittests, so shouldn't it be renamed to testparsers.py? 3) I noticed that there are a number of tests in GeoOpt that can be done for SP, so should they be only in SP or in both? Cheers, Karol -- written by Karol Langner Tue Sep 4 01:02:43 EDT 2007 |
From: Noel O'B. <bao...@gm...> - 2007-09-04 15:34:35
|
On 04/09/07, Karol Langner <kar...@kn...> wrote: > I think it is a good idea to also clean up the unittests a bit before > releasing 0.8. In the interest of this, I added a "SKIPPED" column in the > test summary and the appropriate code for monitoring this (currently based on > PASS being in the docstring). This way it easier to see where we are skipping > unittests. Also, in my last commit I merged testmodule into testall as Noel > suggested (although the name 'testall' does not reflect its function > anymore!). > > Other issues that you might want to comment on: > 1) there should be more coverage of unittests for methods(?) > 2) should unittests for parsers and methods be either better integrated > (possibly run through the same function) or better separated (in separate > directories)? Presently, testall.py runs only parser unittests, so shouldn't > it be renamed to testparsers.py? > 3) I noticed that there are a number of tests in GeoOpt that can be done for > SP, so should they be only in SP or in both? All of these ideas are good and should be done, but I don't know about doing them right now - perhaps you could do them on a branch (or maybe it's time for cclib-0.8 to branch off)?. For example, rename testall.py to testparsers.py; create a directory parsertests and put testGeoOpt.py etc into these; make it possible to run testparsers.py with "GAMESSUK SP" to just test GAMESSUK SP, or SP everything, or GAMESSUK everything (then we can remove the code for running the test from testSP.py, etc.). On the other hand, I have no problem with adding more tests, so if you want to copy tests from testGeoOpt to testSP, that sounds good to me. > Cheers, > Karol > > -- > written by Karol Langner > Tue Sep 4 01:02:43 EDT 2007 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > cclib-devel mailing list > ccl...@li... > https://lists.sourceforge.net/lists/listinfo/cclib-devel > |
From: Karol L. <kar...@kn...> - 2007-09-04 19:11:05
|
On Tuesday 04 September 2007 11:34, Noel O'Boyle wrote: > On 04/09/07, Karol Langner <kar...@kn...> wrote: > > I think it is a good idea to also clean up the unittests a bit before > > releasing 0.8. In the interest of this, I added a "SKIPPED" column in the > > test summary and the appropriate code for monitoring this (currently > > based on PASS being in the docstring). This way it easier to see where we > > are skipping unittests. Also, in my last commit I merged testmodule into > > testall as Noel suggested (although the name 'testall' does not reflect > > its function anymore!). > > > > Other issues that you might want to comment on: > > 1) there should be more coverage of unittests for methods(?) > > 2) should unittests for parsers and methods be either better integrated > > (possibly run through the same function) or better separated (in separate > > directories)? Presently, testall.py runs only parser unittests, so > > shouldn't it be renamed to testparsers.py? > > 3) I noticed that there are a number of tests in GeoOpt that can be done > > for SP, so should they be only in SP or in both? > > All of these ideas are good and should be done, but I don't know about > doing them right now - perhaps you could do them on a branch (or maybe > it's time for cclib-0.8 to branch off)?. For example, rename > testall.py to testparsers.py; create a directory parsertests and put > testGeoOpt.py etc into these; make it possible to run testparsers.py > with "GAMESSUK SP" to just test GAMESSUK SP, or SP everything, or > GAMESSUK everything (then we can remove the code for running the test > from testSP.py, etc.). I'll be more than happy to do all that since it'll clarify the tests, but I'll wait until after the release. It probably won't be as simple as adding a few lines like the commit I made yesterday. Still, I wanted to mention the things here, since I would otherwise forget about them soon. > On the other hand, I have no problem with adding more tests, so if you > want to copy tests from testGeoOpt to testSP, that sounds good to me. That I will do - no harm in having more tests... -- written by Karol Langner Tue Sep 4 21:00:57 EDT 2007 |
From: Karol L. <kar...@kn...> - 2007-09-05 21:19:48
|
On Tuesday 04 September 2007 11:34, Noel O'Boyle wrote: > On the other hand, I have no problem with adding more tests, so if you > want to copy tests from testGeoOpt to testSP, that sounds good to me. A follow up on this... the only test methods that SP and GeoOpt don't have in common is the two for overlaps (testaooverlaps and testdimaooverlaps). You could consider taking testdimmocoeffs out of GeoOpt.py, since a number of the GeoOpt test files currently don't have mocoeffs (Jaguar, Gaussian) or only the first few virtuals (Jaguar, GAMESS-UK). On the other hand, often atombasis comes along with mocoeffs output. Also, a few tests still fail for ADF - I fixed some but some new ones fail after I copied them from testGeoOpt. Most notably, testscfenergies fails for testSP, which should NOT be happening!!! -- written by Karol Langner Wed Sep 5 23:04:48 EDT 2007 |
From: Adam T. <a-t...@st...> - 2007-09-06 00:16:31
|
> Also, a few tests still fail for ADF - I fixed some but some new > ones fail > after I copied them from testGeoOpt. Most notably, testscfenergies > fails for > testSP, which should NOT be happening!!! Weird. I didn't notice any of my recent ADF commits affecting this, although it was dying on Jaguar tests. I also don't see it going into the new code I added since it's not logging warning messages for the basicADF tests. Reverting to revision 745 (before my commits) doesn't fix the problem either. Adam |