<div dir="ltr">Hi Sabeen,<div><br></div><div>I think, that Pavlo described whole picture really nice.</div><div>So I'd like just to add couple my thoughts below:<br><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Regards,<div>Sergey.</div></div></div></div>
<br><div class="gmail_quote">On 12 September 2015 at 15:08, Pavlo Shchelokovskyy <span dir="ltr"><<a href="mailto:pshchelokovskyy@mirantis.com" target="_blank">pshchelokovskyy@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Sabeen,<br>
<br>
thank you for the effort :) More tests is always better than less, but<br>
unfortunately we are limited by the power of VM and time available for<br>
gate jobs. This is why we do no exhaustive functional testing of all<br>
resource plugins APIs, as every time a test goes out and makes an<br>
async API call to OpenStack, like create a server, it always consumes<br>
time, and often consumes resources of VM that runs other tests of the<br>
same test suit as well (we do run them in parallel) making other tests<br>
also slower to some degree. Also, even for not-async/lightweight<br>
resources (e.g. SaharaNodeGroupTemplate), testing all of them requires<br>
running a corresponding OpenStack service on the gate job, which will<br>
consume its resources even further.<br></blockquote><div><br></div><div>More over new additional services make devstack installation longer, so </div><div>as result we have less time for running tests.</div><div>Note, that we also should be careful during adding new tests, because as</div><div>Pavlo mentioned, we run them in parallel. I suppose, that everyone try</div><div>to use unique names for stacks and for internal resources or use only </div><div>random ids, but anyway want to remind do it carefully ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Below are my thoughts and comments inline:<br>
<span class=""><br>
On Fri, Sep 11, 2015 at 6:46 PM, Sabeen Syed <<a href="mailto:sabeen.syed@rackspace.com">sabeen.syed@rackspace.com</a>> wrote:<br>
> Hi All,<br>
><br>
> My coworker and I would like to start filling out some gaps in api coverage<br>
> that we see in the functional integration tests. We have one patch up for<br>
> review (<a href="https://review.openstack.org/#/c/219025/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/219025/</a>). We got a comment saying<br>
> that any new stack creation will prolong the testing cycle. We agree with<br>
> that and it got us thinking about a few things -<br>
<br>
</span>this test should use the TestResource (or even RandomString if you do<br>
not need to ensure a particular order of events), as there is no point<br>
of using an actual server for the assertions this test makes on<br>
stack/resource events.<br></blockquote><div><br></div><div>I personally prefer TestResource, because it's more flexible and </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> We are planning on adding tests for the following api's: event api's,<br>
> template api's, software config api's, cancel stack updates, check stack<br>
> resources and show resource data. These are the api's that we saw aren't<br>
> covered in our current integration tests. Please let us know if you feel we<br>
> need tests for these upstream, if we're missing something or if it's already<br>
> covered somewhere.<br>
<br>
</span>Just make sure all (ideally) of them use TestResource/RandomStrings.<br>
You might still have to tweak it a bit to support a successful/failed<br>
check though. There is a test for SC/SD in functional (and I actually<br>
wonder what is it doing in functional but not scenario), is it not<br>
enough?<br>
<span class=""><br>
> To conserve the creation of stacks would it make sense to add one test and<br>
> then under that we could call sub methods that will run tests against that<br>
> stack. So something like this:<br>
><br>
> def _test_template_apis()<br>
><br>
> def _test_softwareconfig_apis()<br>
><br>
> def _test_event_apis()<br>
><br>
> def test_event_template_softwareconfig_apis(self):<br>
><br>
> stack_id = self.stack_create(…)<br>
><br>
> self._test_template_apis(stack_id)<br>
><br>
> self._test_event_apis(stack_id)<br>
><br>
> self._test_softwareconfig_apis(stack_id)<br>
<br>
</span>If you use TestResource and the like, the time to create a new stack<br>
for each test is not that long. And it is much better to have API<br>
tests separated as actual unit tests, otherwise failure in one API<br>
will fail the whole test which only leaves the developer wondering<br>
"what was that?" and makes it harder to find the root cause.<br>
<span class=""><br>
><br>
> The current tests are divided into two folders – scenario and functional. To<br>
> help with organization - under the functional folder, would it make sense to<br>
> add an 'api' folder, 'resource' folder and 'misc folder? Here is what we're<br>
> thinking about where each test can be put:<br>
><br>
> API folder - test_create_update.py, test_preview.py<br>
><br>
> Resource folder – test_autoscaling.py, test_aws_stack.py,<br>
> test_conditional_exposure.py, test_create_update_neutron_port.py,<br>
> test_encryption_vol_type.py, test_heat_autoscaling.py,<br>
> test_instance_group.py, test_resource_group.py, test_software_config.py,<br>
> test_swiftsignal_update.py<br>
><br>
> Misc folder - test_default_parameters.py, test_encrypted_parameter.py,<br>
> test_hooks.py, test_notifications.py, test_reload_on_sighup.py,<br>
> test_remote_stack.py, test_stack_tags.py, test_template_resource.py,<br>
> test_validation.py<br>
><br>
> Should we add to our README? For example, I see that we use TestResource as<br>
> a resource in some of our tests but we don't have an explanation of how to<br>
> set that up. I'd also like add explanations about the pre-testhook and<br>
> post-testhook file and how that works and what each line does/what test it's<br>
> attached to.<br>
<br>
</span>By all means :) If it flattens the learning curve for new Heat<br>
contributors, it's even better.<br>
<span class=""><br>
> For the tests that we're working on, should we be be adding a blueprint or<br>
> task somewhere to let everybody know that we're working on it so there is no<br>
> overlap?<br>
<br>
</span>File a bug against Heat, make it a wishlist priority, and add a tag it<br>
'functional-tests'. Assign to yourself at will :) but please check out<br>
what we already have filed:<br>
<br>
<a href="https://bugs.launchpad.net/heat/+bugs?field.tag=functional-tests" rel="noreferrer" target="_blank">https://bugs.launchpad.net/heat/+bugs?field.tag=functional-tests</a><br>
<span class=""><br>
> From our observations, we think it would be beneficial to add more comments<br>
> to the existing tests.  For example, we could have a minimum of a short<br>
> blurb for each method.  Comments?<br>
<br>
</span>A (multi-line) doc string for module/test method would suffice. For<br>
longer scenario tests we already do this describing a scenario the<br>
test aim to pass through.<br>
<span class=""><br>
> Should we add a 'high level coverage' summary in our README?  It could help<br>
> all of us know at a high level where we are at in terms of which resources<br>
> we have tests for and which api's, etc.<br>
<br>
</span>As for APIs - I believe we could use some functional test coverage<br>
tool. I am not sure if there is a common thing already settled for in<br>
the community though. It might be a good cross-project topic to<br>
discuss during summit with Tempest community, they might already have<br>
something in the works.<br>
<br>
As for resources - we do try to exercise the native Heat ones that are<br>
there to provide the functionality of Heat itself (ASGs, RGs etc), but<br>
AFAIK we have no plans on deep testing all the other resources in a<br>
functional way.<br>
<span class=""><br>
><br>
> Let us know what you all think!<br>
<br>
</span>Thanks again for bringing this up. "If it is not tested - it does not works" :)<br>
<br>
Best regards,<br>
<br>
Dr. Pavlo Shchelokovskyy<br>
Senior Software Engineer<br>
Mirantis Inc<br>
<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>