+1 Yes we could expose more API methods in Mock IaaS to make those configurable dynamically.
On Fri, May 22, 2015 at 3:22 PM, Reka Thirunavukkarasu <r...@wso2.com> wrote: > Hi Isuru, > > It will be good initiative for adding more samples. Can we keep the > mock-iaas.xml and deploy or undeploy or scaleup or scaledown timeout > configurable per sample wise? So that we can assert based on the timeout > for deploy or undeploy or scaleup or scaledown scenarios where we can > calculate the timeout based on the parameters given in the mock-iaas.xml. > WDYT? > > However I'm not sure how feasible is to test the scaleup and scaledown. > This is just my thought. > > Thanks, > Reka > > On Fri, May 22, 2015 at 12:13 PM, Isuru Haththotuwa <isu...@apache.org> > wrote: > >> Hi Devs, >> >> Did the initial changes and tested locally. This provides the ability to >> easily write tests for scenarios which are hard to cover by unit tests, due >> to distributed nature, etc. The initial abstracted API is shown below, >> which is overriden for artifact specific implementation. >> >> However, I would not commit this now to master since the community is >> preparing for 4.1.0 release. Will try to merge and push after 4.1.0 is done. >> >> /** >> * Deploy the artifact in the file ${definitionFileName}.json by >> calling the deploy.sh script >> * under samples/xxx/scripts/. >> * The file name excluding .json part is passed to the script to >> locate the relevant artifact definition. >> * >> * @param iaas IaaS type >> * @param definitionFileName definition file name, excluding .json >> suffix >> * @return output from the bash command execution >> */ >> * public String deploy (String iaas, String definitionFileName)* >> >> /** >> * Assert if an artifact is deployed with the given id >> * >> * @param artifactId artifact id to check >> */ >> *public void assertDeployed (String artifactId)* >> >> /** >> * Undeploys the artifact with id 'artifactId', by calling the >> undeploy.sh script under samples/xxx/scripts. >> * The iaas and artifact id is passed as a parameter to the script. >> * >> * @param artifactId id of the artifact to undeploy >> * @return output from the bash command execution >> */ >> *public String undeploy (String artifactId)* >> >> /** >> * Executes the script get.sh under samples/xxxx/scripts and returns >> the command output >> * >> * @param artifactId id of artifact to GET >> * @return output of the command execution >> */ >> * public String get (String artifactId)* >> >> /** >> * Assert if no artifact is deployed with the id 'artifactId' >> * >> * @param artifactId id of the artifact to check >> */ >> * public void assertNotDeployed (String artifactId)* >> >> /** >> * Get the relevant artifact directory >> * >> * @return path to the artifact directory >> */ >> * protected String getArtifactLocation ()* >> >> >> On Mon, May 11, 2015 at 12:00 PM, Udara Liyanage <ud...@wso2.com> wrote: >> >>> Hi, >>> >>> +1 for generic approach so we can automate any sample without much >>> change. >>> >>> >>> On Mon, May 11, 2015 at 11:55 AM, Isuru Haththotuwa <isu...@apache.org> >>> wrote: >>> >>>> Hi Imesh, >>>> >>>> Thanks for the feedback. >>>> >>>> What I tried out is similar to what is there currently; I added a >>>> script for each operation and have it parameterized to call the relevant >>>> file. >>>> >>>> For an example, in the samples/cartridges-groups directory, there will >>>> be scripts for common operations; deploy, undeploy, etc. The scripts are >>>> parameterized to take an input specifying which group to deploy/undeploy, >>>> etc. These scripts will be called from the group related test utility >>>> methods. Following this approach, we can call any operation on any of the >>>> cartridges, groups and policies. >>>> >>>> On Mon, May 11, 2015 at 12:39 AM, Imesh Gunaratne <im...@apache.org> >>>> wrote: >>>> >>>>> Hi Isuru, >>>>> >>>>> +1 for improving the Integration Test Framework with utility methods. >>>>> >>>>> Currently we directly invoke the deploy.sh script and it internally >>>>> deploy cartridges, cartridge groups, policies, etc. How are we planning to >>>>> do this with the new approach? It would be better if you could send the >>>>> refactored code. >>>>> >>>>> Thanks >>>>> >>>>> On Mon, May 11, 2015 at 12:12 AM, Isuru Haththotuwa <isu...@apache.org >>>>> > wrote: >>>>> >>>>>> Hi Devs, >>>>>> >>>>>> I had a look to see how we can improve the code coverage with unit >>>>>> testing. There are a few challenges for this in Stratos: >>>>>> >>>>>> 1. Operations are not local to a single component - One component >>>>>> calls other to do verifications, etc. Example: deploying a service >>>>>> group; >>>>>> Autoscaler will call CC to verify the cartridge details >>>>>> 2. Services are not simple, hard to mock - Since the exposed >>>>>> axis2 services are complex, its hard to mock them using available >>>>>> tools. We >>>>>> can still do this bit will involve some re-factoring to the code. >>>>>> >>>>>> As a potential solution to improve the tests, I tried to use the >>>>>> integration test mechanism and adapt it to test simple flows as well; >>>>>> deploying and validating various aspects of Service Groups (dependencies, >>>>>> startup orders, etc.), different kinds of policies used in Stratos, etc. >>>>>> Using the integration test mechanism solves the problem of operations not >>>>>> being local and difficulty to mock them; the Stratos server and MB can be >>>>>> used to execute any flow and test it. >>>>>> >>>>>> What I propose is to add a layer on top of the currently integration >>>>>> tests framework to expose a set of utility methods to deploy cartridges, >>>>>> groups, policies, etc. to help developers to write tests using those >>>>>> easily. All the tests will be executed against a single Stratos Server >>>>>> without starting a separate server each time. Did some refactoring >>>>>> locally >>>>>> to suit this purpose and wrote several simple tests as well, which seem >>>>>> to >>>>>> work well. >>>>>> >>>>>> Please share your thoughts. >>>>>> >>>>>> -- >>>>>> Thanks and Regards, >>>>>> >>>>>> Isuru H. >>>>>> +94 716 358 048* <http://wso2.com/>* >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Imesh Gunaratne >>>>> >>>>> Senior Technical Lead, WSO2 >>>>> Committer & PMC Member, Apache Stratos >>>>> >>>>> -- >>>>> Thanks and Regards, >>>>> >>>>> Isuru H. >>>>> +94 716 358 048* <http://wso2.com/>* >>>>> >>>>> >>>>> * <http://wso2.com/>* >>>>> >>>>> >>>>> >>> >>> >>> -- >>> >>> Udara Liyanage >>> Software Engineer >>> WSO2, Inc.: http://wso2.com >>> lean. enterprise. middleware >>> >>> web: http://udaraliyanage.wordpress.com >>> phone: +94 71 443 6897 >>> >>> -- >>> Thanks and Regards, >>> >>> Isuru H. >>> +94 716 358 048* <http://wso2.com/>* >>> >>> >>> * <http://wso2.com/>* >>> >>> >>> > > > -- > Reka Thirunavukkarasu > Senior Software Engineer, > WSO2, Inc.:http://wso2.com, > Mobile: +94776442007 > > > -- Imesh Gunaratne Senior Technical Lead, WSO2 Committer & PMC Member, Apache Stratos