[RFC] Multipart support for _urllib_

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Ellerman wrote:

...

> 
> Sure. I'm upgrading my folks computer to dapper tonight, which should
> give me a few hours of sitting around watching apt-get, so I should be
> able to at least get started on some tests.
> 
> Well in general the testing stuff is great, so I don't want to sound
> like I'm whinging. But ..
> 
> I guess the first hurdle is working out _where_ to put the test, and
> if there's already a test for the code you're looking at. AFAICT
> there's no systematic linkage between tests and the code that's being
> tested. That would help, eg. if every method had a comment that said
> "tested by bzrlib/tests/test_foo.py:TestWhatever.test_something()".
> Although I guess in practice it's not always clear, and for blackbox
> tests you actually don't really care what gets tested, jus t that it
> _works_.

We work pretty hard to mirror the source tree. Not that it is perfect,
but generally if there is a 'bzrlib/foo.py' there is a test suite
'bzrlib/tests/test_foo.py'
Or if it is a public command, there should be a test
'bzrlib/tests/blackbox/test_command.py'
At one point all the blackbox tests were in one file, so you have
'bzrlib/tests/blackbox/test_too_much.py'. And it is good form if you are
writing a new test for a command to split out the tests from that file
into a separate file for that command.

Probably we should just do a cleanup pass and split up that file
completely to avoid future confusion.

The only other 'trick' comes into play with our adapted tests. For
things which have multiple implementations of an interface (Transport,
Branch, Repository, WorkingTree), we try to have a directory with
specific tests. Then the test runner grabs those tests and adapts them
to run against each implementation.
(So you only write 'test_get_revision', and it gets adapted to run
against every repository implementation).

> 
> Secondly there's no documentation (AFAIK) on how best to write the
> actual tests. It's reasonably easy to work out by cribbing from other
> tests, but sometimes it's not clear.
> 
> cheers

I'm not sure what documentation you are looking for, which is probably
why it isn't written yet. What would be the most helpful for you?

We have some crufts in our tests, since they really just grew, and not
all of them were cleaned up as we added cleaner apis to help testing.

For testing the new code, I could see a few things.
Move the _offsets_to_ranges to either be a separated function (say in
osutils), or a @staticmethod of the root level transport. (I don't
believe it requires any state).
And then write a test for it in either tests/test_transport.py or
tests/test_osutils.py Which just tests the different overlapping rules.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEmUV0JdeBCYSNAAMRAqH/AKDNBGVkyu4+d0AQj+HUlhxBimu5sgCfVUAT
6cQfa7N4ZQv8v4x8E2rrp8o=
=R7ot
-----END PGP SIGNATURE-----