<div dir="ltr">Hi Chris, <div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">If there's sufficient motivation and time it might make sense to<br></span><span style="font-size:13px">separate the part of gabbi that builds TestCases from the part that<br></span><span style="font-size:13px">runs (and evaluates) HTTP requests and responses. If that happens then<br></span><span style="font-size:13px">integration with tools like Rally and runners is probably possible.</span></blockquote><div><br></div><div><br></div><div>Having separated engine seems like a good idea. It will really simplify stuff </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">So, while this is an interesting idea, it's not something that gabbi<br></span><span style="font-size:13px">intends to be. It doesn't validate existing clouds. It validates code<br></span><span style="font-size:13px">that is used to run clouds.</span><br style="font-size:13px"><span style="font-size:13px">Such a thing is probably possible (especially given the fact that you<br></span><span style="font-size:13px">can give a "real" host to gabbi tests) but that's not the primary<br></span><span style="font-size:13px">goal.</span></blockquote><div><br></div><div><br></div><div>This seems like a huge duplication of efforts. I mean operators will write own </div><div>tools developers own... Why not just resolve more common problem: </div><div>"Does it work or not?"</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">But if you are concerned about individual test times gabbi makes every<br></span><span style="font-size:13px">request an individual TestCase, which means that subunit can record times<br></span><span style="font-size:13px">for it. Here's a sample of the output from running gabbi's own gabbi<br></span><span style="font-size:13px">tests:</span><br style="font-size:13px"><span style="font-size:13px">$ python -m subunit.run discover gabbi |subunit-trace<br></span><span style="font-size:13px">[...]<br></span><span style="font-size:13px">gabbi.driver.test_intercept_</span><u style="font-size:13px"></u><span style="font-size:13px">se</span><span style="font-size:13px">lf_inheritance_of_defaults.</span><u style="font-size:13px"></u><span style="font-size:13px">tes</span><span style="font-size:13px">t_request [0.027512s] ... ok<br></span><span style="font-size:13px">[...]</span></blockquote><div><br></div><div><br></div><div>What is "test_request" Just one RestAPI call? </div><div><br></div><div>Btw the thin that I am interested how they are all combined?</div><div><br></div><div> -> fixtures.set</div><div>    -> run first Rest call</div><div>    -> run second Rest call</div><div>    ...</div><div> -> fixtures.clean</div><div><br></div><div><div>Something like that? </div></div><div><br></div><div>And where are you doing cleanup? (like if you would like to test only creation of resource?) </div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 12:37 AM, Chris Dent <span dir="ltr"><<a href="mailto:chdent@redhat.com" target="_blank">chdent@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 13 Jan 2015, Boris Pavlovic wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The Idea is brilliant. I may steal it! =)<br>
</blockquote>
<br></span>
Feel free.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But there are some issues that will be faced:<br>
<br>
1) Using as a base unittest:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
python -m subunit.run discover -f gabbi | subunit2pyunit<br>
</blockquote>
<br>
So rally team won't be able to reuse it for load testing (if we directly<br>
integrate it) because we will have huge overhead (of discover stuff)<br>
</blockquote>
<br></span>
So the use of unittest, subunit and related tools are to allow the<br>
tests to be integrated with the usual OpenStack testing handling. That<br>
is, gabbi is primarily oriented towards being a tool for developers to<br>
drive or validate their work.<br>
<br>
However we may feel about subunit, testr etc they are a de facto<br>
standard. As I said in my message at the top of the thread the vast<br>
majority of effort made in gabbi was getting it to be "tests" in the<br>
PyUnit view of the universe. And not just appear to be tests, but each<br>
request as an individual TestCase discoverable and addressable in the<br>
PyUnit style.<br>
<br>
In any case, can you go into more details about your concerns with<br>
discovery? In my limited exploration thus far the discovery portion is<br>
not too heavyweight: reading the YAML files.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2.3) It makes it hardly integratabtle with other tools. Like Rally..<br>
</blockquote>
<br></span>
If there's sufficient motivation and time it might make sense to<br>
separate the part of gabbi that builds TestCases from the part that<br>
runs (and evaluates) HTTP requests and responses. If that happens then<br>
integration with tools like Rally and runners is probably possible.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Usage by Operators is hard in case of N projects.<br>
</blockquote>
<br></span>
This is not a use case that I really imagined for gabbi. I didn't want<br>
to create a tool for everyone, I was after satisfying a narrow part of<br>
the "in tree functional tests" need that's been discussed for the past<br>
several months. That narrow part is: legible tests of the HTTP aspects<br>
of project APIs.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Operators would like to have 1 button that will say (does cloud work or<br>
not). And they don't want to combine all gabbi files from all projects and<br>
run test.<br>
</blockquote>
<br></span>
So, while this is an interesting idea, it's not something that gabbi<br>
intends to be. It doesn't validate existing clouds. It validates code<br>
that is used to run clouds.<br>
<br>
Such a thing is probably possible (especially given the fact that you<br>
can give a "real" host to gabbi tests) but that's not the primary<br>
goal.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4) Using subunit format is not good for functional testing.<br>
<br>
It doesn't allow you to collect detailed information about execution of<br>
test. Like for benchmarking it will be quite interesting to collect<br>
durations of every API call.<br>
</blockquote>
<br></span>
I think we've all got different definitions of functional testing. For<br>
example in my own personal defintion I'm not too concerned about test<br>
times: I'm worried about what fails.<br>
<br>
But if you are concerned about individual test times gabbi makes every<br>
request an individual TestCase, which means that subunit can record times<br>
for it. Here's a sample of the output from running gabbi's own gabbi<br>
tests:<br>
<br>
$ python -m subunit.run discover gabbi |subunit-trace<br>
[...]<br>
gabbi.driver.test_intercept_<u></u>self_inheritance_of_defaults.<u></u>test_request [0.027512s] ... ok<br>
[...]<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
-- <br>
Chris Dent tw:@anticdent freenode:cdent<br>
<a href="https://tank.peermore.com/tanks/cdent" target="_blank">https://tank.peermore.com/<u></u>tanks/cdent</a><br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>