On 05/07/2014 10:23 AM, Ken'ichi Ohmichi wrote: > Hi David, > > 2014-05-07 22:53 GMT+09:00 David Kranz <dkr...@redhat.com>: >> I just looked at a patch https://review.openstack.org/#/c/90310/3 which was >> given a -1 due to not checking that every call to list_hosts returns 200. I >> realized that we don't have a shared understanding or policy about this. We >> need to make sure that each api is tested to return the right response, but >> many tests need to call multiple apis in support of the one they are >> actually testing. It seems silly to have the caller check the response of >> every api call. Currently there are many, if not the majority of, cases >> where api calls are made without checking the response code. I see a few >> possibilities: >> >> 1. Move all response code checking to the tempest clients. They are already >> checking for failure codes and are now doing validation of json response and >> headers as well. Callers would only do an explicit check if there were >> multiple success codes possible. >> >> 2. Have a clear policy of when callers should check response codes and apply >> it. >> >> I think the first approach has a lot of advantages. Thoughts? > > Thanks for proposing this, I also prefer the first approach. > We will be able to remove a lot of status code checks if going on > this direction. > It is necessary for bp/nova-api-test-inheritance tasks also. > Current https://review.openstack.org/#/c/92536/ removes status code checks > because some Nova v2/v3 APIs return different codes and the codes are already > checked in client side. > > but it is necessary to create a lot of patch for covering all API tests. > So for now, I feel it is OK to skip status code checks in API tests > only if client side checks are already implemented. > After implementing all client validations, we can remove them of API > tests.
Do we still have instances where we want to make a call that we know will fail and not through the exception? I agree there is a certain clarity in putting this down in the rest client. I just haven't figured out if it's going to break some behavior that we currently expect. -Sean -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev