My understanding is that VCR will capture the HTTP test request/responses and comparison to some baseline will indicate that the API is behaving as expected.
Forgive me if I’m misunderstanding something fundamental about the VCR based testing approach. Some questions to helop me understand:
Are the HTTP responses going to be the same between runs and between systems?
How deep are the comparisons of the HTTP responses? Are you thinking of doing byte level comparisions of the entire response data, including headers etc?
Often the contents of the HTTP headers vary for a whole bunch of reasons.
Also if there is a proxy in the middle that can easily rewrite the whole request and response. I’m guessing a byte level comparison of the responses would fail.
If it was the content of the responses being compared then that’s likely to work but that’s not really what VCR is about, right?
Am I understanding the VCR approach correctly?
as
On 2 Jan 2015, at 3:40 pm, Barry Warsaw <barry@python.org> wrote:
On Dec 27, 2014, at 01:16 PM, Florian Fuchs wrote:
So far we haven't found a perfect solution for testing packages that rely heavily on the MM3 REST API. As far as mailman.client, Postorius and HK are concerned, testing without *some* core integration doesn't make too much sense IMO, because any changes in the API would go unnoticed.
I'm playing with a solution that involves the use of the 'vcr' package, which as its name implies (well, at least for us, um, mature programmers ;) is a facility to record and replay HTTP traffic. It's compatible with both Python 2 and 3 and is available on the Cheeseshop.
So the basic idea is to set up an MM3 installation (tox --notest -r
suffices), then start up its REST server with a fresh mailman.db, and run the
test suite against it. This will capture the traffic in a yaml file, which
we could ship with mailman.client.
Then to run the test suite, you'd use vcr in replay mode against the captured yaml file. Any time the API changes, you'd have to re-record the traffic against a fresh database.
I have a branch that's working in this direction and it's promising, but I've also had to rewrite the testing infrastructure for mailman.client, and make some other changes. It also points out what I think are some bugs in Mailman core, so I'm working those out on my py3 branch in parallel.
It's not yet ready for review, but if you want to keep an eye on things, look here: lp:~barry/mailman.client/bilingual
Feel free to provide feedback on the approach, or the changes so far, but I will submit a merge proposal when/if it's ready to go.
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9