Menu
▾
▴
configobj-develop
|
From: Stefan P. <pa...@ik...> - 2011-01-05 16:38:39
|
Hi, I was requested to include tests together with any patches I might make. After looking at the included tests I have to say that I'm a bit confused as to where and how the tests should be included. It seems like there are some doctests in the main source files, configobj.py and validate.py. Mostly similar, yet different tests can be found in test_configobj.py. Yet more tests can be found in the functionaltests subdirectory. Currently some tests are failing on Python 2.7 due to how the tests are written. Instead of fixing the same doctest bugs in 2 or 3 different places, would it be better to take some time and consolidate all the different tests in one place? Where should the test be stored? Personally I prefer to store tests outside the main source code because I find it cleaner, but others might disagree. -- Stefan Parviainen |
|
From: Michael F. <fuz...@vo...> - 2011-01-05 16:44:27
|
On 05/01/2011 16:38, Stefan Parviainen wrote: > Hi, > > I was requested to include tests together with any patches I might > make. After looking at the included tests I have to say that I'm a bit > confused as to where and how the tests should be included. It seems > like there are some doctests in the main source files, configobj.py > and validate.py. Mostly similar, yet different tests can be found in > test_configobj.py. Yet more tests can be found in the functionaltests > subdirectory. > > Currently some tests are failing on Python 2.7 due to how the tests > are written. Instead of fixing the same doctest bugs in 2 or 3 > different places, would it be better to take some time and consolidate > all the different tests in one place? Where should the test be stored? > Personally I prefer to store tests outside the main source code > because I find it cleaner, but others might disagree. > Hey Stefan, Short answer - best to add new tests as unit tests rather than doctests and patches to fix existing failures on 2.7 are appreciated but probably best done separately. ConfigObj and validate were originally tested by doctests in the source code only. This got unwieldy (i.e. horrible) and most of the doctests were moved out of the configobj source and into their own file. Over time I came to hate doctests more and more and I write new tests as unit tests. The tests that were left in the source code of configobj.py are only ones I thought were useful as "documentation" in the docstrings. It is possible that some of those should be deleted if they're duplicated in the test file and are a maintenance burden. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html |
|
From: David H. <neg...@gm...> - 2011-01-05 17:15:50
|
> I came to hate doctests more and more and I write new tests as unit > tests. Yay!!! :) > The tests that were left in the source code of configobj.py are only > ones I thought were useful as "documentation" in the docstrings. It is > possible that some of those should be deleted if they're duplicated in > the test file and are a maintenance burden. If you're no longer running doctests or encouraging others to, then if the stuff still in the source remains valuable from a reference/usage point of view it should probably at least be made to not look like doctests, and just appear as straight-up inline documentation. Otherwise people familiar with the format will think they're legitimately active tests and probably will adopt a 'when in rome' approach. If they're only of marginal doc value then I think they could be stripped out altogether. Both configobj and validate are well documented and that allows cleanliness and maintainability of the source code to have higher priority. regards, -hoss David Hostetler neg...@gm... |
|
From: Michael F. <fuz...@vo...> - 2011-01-05 17:18:25
|
On 05/01/2011 17:15, David Hostetler wrote: >> I came to hate doctests more and more and I write new tests as unit >> tests. > Yay!!! :) > > >> The tests that were left in the source code of configobj.py are only >> ones I thought were useful as "documentation" in the docstrings. It is >> possible that some of those should be deleted if they're duplicated in >> the test file and are a maintenance burden. > If you're no longer running doctests or encouraging others to, then if > the stuff still in the source remains valuable from a reference/usage > point of view it should probably at least be made to not look like > doctests, and just appear as straight-up inline documentation. Well - actually the *only* good use of doctests is to make examples executable (and therefore signal if the example break). If the tests currently inline can be made to look better whilst retaining testability then I'd be open to that change. > Otherwise people familiar with the format will think they're > legitimately active tests and probably will adopt a 'when in rome' > approach. If they're only of marginal doc value then I think they > could be stripped out altogether. Both configobj and validate are > well documented and that allows cleanliness and maintainability of the > source code to have higher priority. > Ones that are of marginal doc value can definitely be stripped out. Michael > regards, > > -hoss > > David Hostetler > neg...@gm... > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Configobj-develop mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/configobj-develop -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html |
Thanks for helping keep SourceForge clean.
X