tests module was broken down as above mentioned sub modules. Since We still use tests module , those sub modules are not enabled by setting <skipTests >true</skipTests> in surefire configurations. once we can verify that all tests are passed, we can enable sub modules and remove the tests module.
On Tue, Sep 17, 2013 at 5:59 PM, Krishantha Samaraweera <[email protected] > wrote: > Hi Nuwan, > > I think we don't need to worry about disk space etc... Splitting the > package will minimize the intermittent test failure due to heavily load on > ESB server which runs with default perf parameters. On the other hand it > will minimize debugging effort and even product team will find it easy to > assign modules among themselves and fix tests, if there are any test > failures. > > Thanks, > > Krishantha Samaraweera > Senior Technical Lead - Test Automation. > Mobile: +94 7777 599 18; blog: http://opensource-soa.blogspot.com/ > WSO2, Inc.; http://wso2.com/ > lean . enterprise . middlewear. > > > On Tue, Sep 17, 2013 at 12:24 PM, Nuwan Wimalasekara <[email protected]>wrote: > >> >> Hi >> I am working on $subject. Our aim is to decrease the ESB server stress >> while tests are executing. Currently around 900 test cases in one module >> named tests are running against a one ESB server started by test framework >> and it takes nearly two hours to complete all test cases. In all the test >> cases there are lots of admin services callings , service invocations , >> server configurations (axis2.xml) and server restart calling happens every >> time. Sometimes it will introduce some intermittent test failures. So >> breaking the tests modules will ease of running test cases and >> debugging test failures. >> >> So we tried to break down the Integration tests into 5 modules as >> mentioned bellow! >> >> 1) tests-services - Proxy, Security, Endpoint, Sequence, Localentry, >> Rest, jaxrs, schedule task related test cases >> 2) tests-mediators - Test Cases related to mediators, message >> processors, message stores, priority executors >> 3) tests-transports - JMS,VFS, Nhttp, PTT, VFS,TCP, HL7, .... etcrelated >> test cases >> 4) tests-samples - ESB sample related test cases >> 5) tests-others - Other test cases >> >> Then in each of module, test framework starts a fresh ESB server and test >> are being executed against that server. >> >> But there are few concerns we have to consider >> 1) We can guarantee the number of test cases and time to complete running >> in each module are same . Those count varies from module to module since >> some modules have more test cases. >> 2) It needs the space more than a space used tests module. >> 3) Need to review 5 test reports >> >> Really appreciate your ideas for above structure for integration test for >> ESB to continue the work. >> >> Thanks, >> Nuwanw >> -- >> Nuwan Wimalasekara >> Senior Software Engineer - Test Automation >> WSO2, Inc.: http://wso2.com >> lean. enterprise. middleware >> >> phone: +94 71 668 4620 >> >> >> >> > -- Nuwan Wimalasekara Senior Software Engineer - Test Automation WSO2, Inc.: http://wso2.com lean. enterprise. middleware phone: +94 71 668 4620
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
