I tend to agree with your assessment (use test data) On 12/24/12 10:03 PM, "Prasanna Santhanam" <t...@apache.org> 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. > >-- >Prasanna.,
