>> For the api stuff, sure thats fine. i just think the overall coverage of the >> review will be quite low if we are only testing the API via fake code.
We're in agreement here, I think. I will say though that if the people working on Mongo want to test it early, and go beyond simply using the client to manually confirm stuff, it should be possible to run the existing tests by building a different image and running a subset, such as "--group=dbaas.guest.shutdown". IIRC those tests don't do much other than make an instance, see it turn to ACTIVE, and delete it. It would be a worthwhile spot test to see if it adheres to the bare-minimum Trove API. ________________________________________ From: Michael Basnight [mbasni...@gmail.com] Sent: Monday, October 21, 2013 12:19 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Trove] Testing of new service types support On Oct 21, 2013, at 10:02 AM, Tim Simpson wrote: > Can't we say that about nearly any feature though? In theory we could put a > hold on any tests for feature work saying it > will need to be redone when Tempest integrated is finished. > > Keep in mind what I'm suggesting here is a fairly trivial change to get some > validation via the existing fake mode / integration tests at a fairly small > cost. Of course we can do the old tests. And for this it might be the best thing. The problem i see is that we cant do real integration tests w/o this work, and i dont want to integrate a bunch of different service_types w/o tests that actually spin them up and run the guest, which is where 80% of the "new" code lives for a new service_type. Otherwise we are running fake-guest stuff that is not a good representation. For the api stuff, sure thats fine. i just think the overall coverage of the review will be quite low if we are only testing the API via fake code. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
