[openstack-dev] Questions regarding Functional Testing (Paris Summit)
Sean Toner
stoner at redhat.com
Fri Dec 12 18:04:05 UTC 2014
Hi everyone,
I have been reading the etherpad from the Paris summit wrt to moving the
functional tests into their respective projects
(https://etherpad.openstack.org/p/kilo-crossproject-move-func-tests-to-projects). I am mostly interested this from the nova project
perspective. However, I still have a lot of questions.
For example, is it permissible (or a good idea) to use the python-
*clients as a library for the tasks? I know these were not allowed in
Tempest, but I don't see why they couldn't be used here (especially
since, AFAIK, there is no testing done on the SDK clients themselves).
Another question is also about a difference between Tempest and these
new functional tests. In nova's case, it would be very useful to
actually utilize the libvirt library in order to touch the hypervisor
itself. In Tempest, it's not allowed to do that. Would it make sense
to be able to make calls to libvirt within a nova functional test?
Basically, since Tempest was a "public" only library, there needs to be
a different set of rules as to what can and can't be done. Even the
definition of what exactly a functional test is should be more clearly
stated.
For example, I have been working on a project for some nova tests that
also use the glance and keystone clients (since I am using the python
SDK clients). I saw this quote from the etherpad:
" Many "api" tests in Tempest require more than one service (eg, nova
api tests require glance)
Is this an API test or an integration test or a functional test?
sounds to me like cross project integration tests +1+1"
I would disagree that a functional test should belong to only one
project. IMHO, a functional test is essentially a black box test that
might span one or more projects, though the projects should be related.
For example, I have worked on one of the new features where the config
drive image property is set in the glance image itself, rather than
specified during the nova boot call.
I believe that's how a functional test can be defined. A black box test
which may require looking "under the hood" that Tempest does not allow.
Has there been any other work or thoughts on how functional testing
should be done?
Thanks,
Sean Toner
More information about the OpenStack-dev
mailing list