> Madan U Sreenivasan wrote:
> > - There are some existing test cases in
> > subversion/bindings/swig/python/tests/. But, these are not comprehensive
> > (IMHO), and more importantly use imports from trac modules. Is there some
> > specific purpose for making the tests dependant on trac?
As Garrett pointed out, our tests don't depend on Trac per se.
However, the Trac test suite provides helpful modules which make it
easy to write test cases for the Python bindings, and we use them. For
example, in our tests, we make use of Trac's
SubversionRepositoryTestSetup class to setup Subversion repositories.
That said, as we continue to extend our test suite, we will probably
find that we will need to do things that
'SubversionRepositoryTestSetup' can't do. If we start to make changes
to 'SubversionRepositoryTestSetup', I agree that we should probably
move it out of the 'trac' namespace so as to clarify that it differs
from the Trac equivalent and has been specialized for use in
Subversion.
On 6/5/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> We are using Trac's python bindings test suite.
True. The "python/tests/trac" directory are directly copied from Trac
with a few minor changes.
However, the tests in "python/tests/*.py" were written specifically
with the Python bindings in mind. Any new tests should be added under
"python/tests", and should not be added under the Trac namespace. (We
are already following this philosophy, so I'm not proposing a change
here.)
> > - The tests only test on file:// based urls. I think we should have tests
> > like our existing cmdline tests, that can be run selectively on file://,
> > http:// and svn://
I agree. The Ruby bindings, for example, don't just test the "file://"
layer, but also the "svn://" layer. Testing "http://" in a simple test
suite is a bit more difficult, but it would definitely be great if we
could add support for this to the Python bindings. By supporting more
layers, we'll detect more bugs, that, for example, might only occur
when additional authentication or authorization code jumps into the
picture.
That said, I would prefer if we focus for now on increasing the
coverage of our existing "file://"-based tests before we start writing
new "svn://" and "http://"-based tests. We'll get a lot more bang for
our buck if we focus on extending the coverage of our existing tests
first.
> Our python bindings are a test of the bindings themselves, not of the C code
> behind the bindings. I think it is sufficient to only perform file://
> testing in the bindings tests because that will exercise the Python-to-C
> translation code in exactly the same way testing over the other RA layers would.
I agree with Mike that it would be more useful to add tests for the
"file://" layer now before we start testing the "svn://" or "http://"
layers.
> > - Given the above two points, I think we should be rewriting the tests.
Please don't rewrite our test suite ;)
Instead, I'd prefer if we focus on extending our test suite to provide
better coverage of the Python bindings. Please take a look at the
following patches for examples:
http://svn.haxx.se/dev/archive-2006-05/0192.shtml
http://svn.haxx.se/dev/archive-2006-05/0847.shtml
Madan, if you could help us write some new tests, similar to the ones
that Jelmer just added, that would be great!
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 5 18:56:45 2006