
<html dir="ltr">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<style type="text/css" id="owaParaStyle"></style>

</head>

<body fpstyle="1" ocsi="0">

<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Based on my previous experiences, I have to advocate the opposite. My quick bullet point list about language bindings:

<div>

<ul>

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

<div>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.</div>

<div><br>

</div>

<div>Daryl</div>

________________________________________<br>

From: Monty Taylor [mordred@inaugust.com]<br>

Sent: Monday, July 01, 2013 9:15 AM<br>

To: openstack-qa@lists.openstack.org<br>

Subject: Re: [openstack-qa] Refactoring Tempest service clients<br>

<br>

<br>

I think that if you do this, you will wind up implementing a parallel<br>

set of client libraries.<br>

<br>

I'm going to take this moment to advocate for just using the client<br>

libraries in tempest instead of direct HTTP, btw. 2 reasons - one - what<br>

Martina brings up - it's hard to write things with the direct HTTP. Two<br>

- we have integration testing for real at this point, whereas we did not<br>

have it when tempest was first written/designed. So the fact that the<br>

client libs are part of the gate should mitigate that.<br>

<br>

But - as always- only my $0.02.<br>

<br>

_______________________________________________<br>

openstack-qa mailing list<br>

openstack-qa@lists.openstack.org<br>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa<br>

</div>

</div>

</body>

</html>