Open Stack

Based on my previous experiences, I have to advocate the opposite. My quick bullet point list about language bindings:

  *   Are too helpful (re-tries, re-auth)
  *   Hide specifics about the response from the tester
  *   Stop the tester from manipulating a request in meaningful ways
  *   Block the tester from injecting useful logging/timing of requests etc

For simple, positive testing I can see the argument that language bindings provide a quick and dirty way to get started, but the downsides are too great for anything beyond basic smoke API testing.

Daryl
________________________________________
From: Monty Taylor [mordred at inaugust.com]
Sent: Monday, July 01, 2013 9:15 AM
To: openstack-qa at lists.openstack.org
Subject: Re: [openstack-qa] Refactoring Tempest service clients


I think that if you do this, you will wind up implementing a parallel
set of client libraries.

I'm going to take this moment to advocate for just using the client
libraries in tempest instead of direct HTTP, btw. 2 reasons - one - what
Martina brings up - it's hard to write things with the direct HTTP. Two
- we have integration testing for real at this point, whereas we did not
have it when tempest was first written/designed. So the fact that the
client libs are part of the gate should mitigate that.

But - as always- only my $0.02.

_______________________________________________
openstack-qa mailing list
openstack-qa at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20130701/9b5933f6/attachment.html>