incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: API Updates: Tracking progress, changes
Date Wed, 26 Dec 2012 20:55:52 GMT
I tend to agree with your assessment (use test data)

On 12/24/12 10:03 PM, "Prasanna Santhanam" <> wrote:

>On Mon, Dec 24, 2012 at 08:22:17PM -0500, Alex Huang wrote:
>> Rohit & Prasanna,
>> I thought about this over the weekend a little bit.  I think testing
>> the entire range of commands really is an automated system test.  I
>> think adding to current set of automated tests is fine but it really
>> serves no purpose in testing the changes in this api refactoring.
>> What you really changed is the processing loop and moving code out
>> to adapters.  The right thing to do is actually to write a test case
>> that tests that main loop and also test drivers for the security
>> adapters.  So test drivers here is different than unit tests.  Unit
>> tests understands how your code works and you can write that too but
>> test drivers loads code specified and tests the interface to make
>> sure in all situations the contract is upheld.
>I sort of agree. The simulator might be heavy-duty for something
>simple like this. And the refactoring doesn't really change the APIs
>at all. It only applies custom annotations for us to do efficient
>lookups while allowing pluggability of adapters.
>Right now with the simulator the flow looks like this:
>otw request -> API server -> mgmt layers -> ...simulator... -> mgmt
>layers -> response builder -> client
>FWIU,  the test driver will basically escape the entire mgmt and agent
>layers. So we have:
>request -> API server -> test driver w/ data -> response builder
>Am I right in understanding that this will basically involve us
>seeding enough data for our test driver's database with the valid
>JSON, request-responses? That could save us a ton of time over the
>simulator+marvin tests.

View raw message