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
