With this approach you are writing something in between unit and integration but more towards integration tests. We can't describe feature level automated tests as pure integration tests as other required components to make it a product are not present. May be we need to come up with new term for this - something like 'feature-testing' :)
We need to decide whether to duplicate tests or not. If we can make sure a particular feature works 100% with feature level tests, then duplicating the same test in product level is not required (This will add extra time overhead to our builds). If you have greater coverage in feature level then tests required for product verification will be minimal. I would like to have a discussion on this with carbon-kernel team to finalize everything. Will send an invitation. Thanks, Krishantha. On Fri, Oct 31, 2014 at 8:06 PM, KasunG Gajasinghe <[email protected]> wrote: > Hi, > > Will we be writing integration tests or unit tests with this approach? If > we are writing integration tests here, then we will have integration tests > in carbon component/feature repos in addition to what we already have in > product repos. > > It's important to have automation tests at product level. So, when writing > a new integration test, how can we decide which repo it should go to? Will > we have to duplicate any test? > > > > On Wed, Oct 29, 2014 at 6:51 PM, Irham Iqbal <[email protected]> wrote: > >> Hi all, >> >> I am working on creating an environment to write test cases to test >> standalone features. With new GIT module components and features should be >> released prior to product releases, so all features must be thoroughly >> tested and should be production ready. Carbon runtime is needed to test the >> standalone features, so our plan is to start carbon-core by installing all >> features resided in a project repository. >> >> For creating test execution environment, all features will be installed >> on carbon-core using carbon-p2-plugin. Before installing we have to create >> p2-repo with relevant features in it. To do that, need to have pom with all >> feature dependencies required (including common dependencies) . P2-repo >> will be created by installing that pom with relevant features specified. >> When installing a feature you have to find out and install all the other >> features this feature is depending on. >> >> After creating carbon-core with all required features, test framework >> dependency will be used with new extension classes to facilitate sever >> management, code coverage generation and user/tenant creation. >> >> I've done a POC to verify feature installation on carbon-core in >> carbon-deployment project and everything seems to work fine. Just need >> clarify whether this is the correct approach for feature level testing and >> any suggestions for alternatives. Kindly expecting your ideas on this. >> >> Attached diagram depict proposed architecture. >> >> >> >> Thanks, >> Iqbal >> >> -- >> Irham Iqbal >> Software Engineer - Test Automation >> WSO2, Inc.: http://wso2.com >> lean. enterprise. middleware >> phone: +94 777888452 >> > > > > -- > > *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. > email: kasung AT spamfree wso2.com > linked-in: http://lk.linkedin.com/in/gajasinghe > blog: http://kasunbg.org > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Krishantha Samaraweera Senior Technical Lead - Test Automation Mobile: +94 77 7759918 WSO2, Inc.; http://wso2.com/ lean . enterprise . middlewear.
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
