INFSO-RI-223782 JRA 2 Testing senarious ETICS AH meeting

INFSO-RI-223782 JRA 2: Testing senarious ETICS AH meeting Budapest, 22 -24 Iune 2009 Eva Takacs, Jozsef Kuti, András Milassin 4 D Soft

Overview • • INFSO-RI-223782 ETICS testing Services JRA 2 tasks GWT Deployment scenario Web services tests Transition to multinode Test Tool Registration System – new developments Conclusion 2

ETICS Testing Services INFSO-RI-223782 • In terms of testing services ETICS provides • Test case/suites/scenarious execution environment • • able to automate test processes (some of the key words: etics-build, etics-test, target commands, properties, dependency mechanism, plugin framework, profiles) Plugin framework allowing the extensability of the framework with specialised tools Plugins – test tools included in the plugin framework 3

New ETICS Testing Services JRA 2 tasks INFSO-RI-223782 Test Tool Registration System • mechanism to register test tools as plugins • a high level, web based registration mechanism to add test tools as plugins to extend the ETICS execution framework • The output of the registration process - the tools are available in the system without the need of system administrator’s intervention 4

New ETICS test services JRA 2 task INFSO-RI-223782 Workflow Designer • Designer tool for multinode deployment/test orchestration • High level frontend to hide the etics-set, etics-get mechanism – technique to store the communication parameters between services Issue with the etics-set, etics-get – the user has to include in his own scripts these commands – powerful mechanism but inconvenient way of usage from the user point of view 5

ETICS does NOT provide INFSO-RI-223782 • Test tools to write tests for the user – ETICS does not write tests • Already existing test scripts – the user has to implement his own scripts 6

INFSO-RI-223782 Deployment test scenario of the Test Tool Registration System 7

ETICS Test system – main architecture INFSO-RI-223782 8

Description of the scenario INFSO-RI-223782 Test Tool Registartion system is a GWT based web application – is the entry point to perform plugins management. As architecture: • GWT based web application (client/server side) • Server side: - webservices for the plugin registartion • for the plugin template generation • The primary purpose of this scenario is to have an automated way of deploying the newly implemented features on various places especially on the test environment to be able to validate the new features not just using the GWT provided in-built browser mechanism – to solve the problem of working locally but doesn’t working remotely. 9

INFSO-RI-223782 Goal of the deployment scenario • to have an automated way of deploying the newly implemented features on various places especially on the (http: //lxetvm 0016. cern. ch: 8080/etics. Portal/#) test environment • to be able to validate the new features not just using the GWT provided in-built browser mechanism - to solve the problem of working locally but not working remotely • to extract the configuration parameters as high as possible (ETICS properties, env variables level if possible) to solve the problem of configuration issues– not to be a „hidden knowledge” of system administrators • to have an environment for running unit tests and static tests • to have an environment for running web service tests • to have an environment for running acceptance and browser compatibility tests (to be done) 10

To sum up the scenario INFSO-RI-223782 Input for the scenario • the developer has implemented a new feature and wants to try it out on the test environment Output of the scenario • the newly built software packages are deployed on the test environment in a very short time (in our case 5 minitues) – the new features can be tried out immediately in ‘production’ 11

Modelling the environment in ETICS INFSO-RI-223782 https: //etics. cern. ch/etics. Portal 12

INFSO-RI-223782 Steps to be performed Preparing the files to be commited into CVS • The developer „prepares” the java files to be commited in CVS • The local configuration parameters will be replaced with global placeholders. For example: @@paramname@@ • In case of new configuration (communication) parameters – they should be added in the deployment script. 13

Steps to be performed Building the packages INFSO-RI-223782 • The jars and wars are created and are copied into the stage dir. • The initial configuration files (service. property, etics. Portal. WA. configuration. xml) (that must be overwritten later on by the deployment script) will be copied into the stagedir. • The deployment script from the test dir of the main component(etics. Portal. WA) will be copied into the stage dir. (Everything needed for deployment is in the stage. Dir) 14

Steps to be performed Deploying the packages INFSO-RI-223782 Deploying of the components is done (from the stage dir deploys. . . ) Deployment scripts for different configurations rebuild. Testsystem. sh – main deploy script without WIKI rebuild. Testsystem. Wiki. sh – main deploy with wiki deploy. Etics. Portal. WA. sh – main deploy without registration system restart. Test. System. sh – start/restart tomcat without deploying the war file 15

Deployment settings INFSO-RI-223782 For example in our case: REG_SYS_SERVER_NAME: http: //lxetvm 0016. cern. ch WF_DESIGNER_URL: https: //n 48. hpcc. sztaki. hu: 8443/gridsphere 16

Steps to be performed Deployment steps for the each component INFSO-RI-223782 • Stops the tomcat and disable firewall • Deletes the necessary folders in the tomcat directory • Copies the initial configuration files (service. properties, etics. Portal. WA. configuration. xml) and wars into tomcat • Deployment script overwrites the initial configuration files to the production ones (see slide 16) • Start httpd, tomcat (Deployment is ready. For example: http: //lxetvm 0016. cern. ch: 8080/etics. Portal or http: //localhost or. . ) 17

Configurations INFSO-RI-223782 • org. etics. testsystem_deployment • – performs build, deployment • org. etics. testsystem_dep_local_wiki • – performs build, deployment with wiki on local host • org. etics. testsystem_build • – performs build without deployment and with plugins running 18

Configuration for testing purposes org. etics. testsystem_build INFSO-RI-223782 Profiles are set (subconfigurations, profiles ) : etics. Portal. WA. build: • checkstyle; findbugs; pmd; jccn; ckjm; plugin. Generation. WS. build • checkstyle; jdepend; findbugs; pmd; jccn; ckjm; plugin. Registration. WS. build • emma; jdepend; findbugs; jccn; ckjm; cobertura; test. System. Portlet. build: • checkstyle; jdepend; pmd; emma; ckjm; cobertura; Report (At this point we are ready with unit tests and static tests and we have metrics. ) 19

Web service test scenario INFSO-RI-223782 Goal: the test scenario is to run webservice tests and to follow the test coverage. The general steps are: • Compile the source of the web service • Instrument the byte code of the web service • Copy emma. jar to the jdk of the tomcat • Create the war file • Deploy the instrumented war file to the tomcat • Run the junit on the client stub • Stop the tomcat • Run emma report 20

INFSO-RI-223782 Technical steps for such a scenario web service deployment with instrumented files The user has to define the build/test process Some required, time-consuming operations of the proceess could be done by the plugins: clean: ant clean -f build-emma. xml init: cp ${emma. location}/emma-2. 0. 5312/lib/emma. jar ${jdk. location}/jre/lib/ext configure: ant prefetch compile -f build-emma. xml compile: ant instrument -f build-emma. xml //plugin emma instrument install: packaging: cp coverage/metadata. emma ${reports. Dir} test: ant emma. dist -f build-emma. xml; sh ${stage. Dir}/deploy. Registration. WS. sh prepublish: (Output: instrumented web service is deployed on tomcat) ( 21

INFSO-RI-223782 Technical steps for such a scenario Creating the stub and the comiling the junit tests clean: init: configure: compile: doc: checkstyle: install: packaging: test: prepublish: ant clean ant dist echo ant test. compile 22

Technical steps for such a scenario Running the tests INFSO-RI-223782 clean: init: cd ${src. location}; ant init run -f build-junit. xml; //plugin junit sh ${tomcat. location}/bin/shutdown. sh; sleep 5; test: cp ${workspace. Dir}/coverage. ec ${reports. Dir} cd ${reports. Dir}; ${jdk. location}/bin/java emma report -sp ${plugin. Registration. WS. src. location}/src/ -r html -in metadata. emma, coverage. ec //plugin emma report Reports emma Reports junit 23

Conclusion INFSO-RI-223782 The tests provided by plugins mechanism (unit tests, standards complience, static analysis, in some cases dynamic analysis) does not require separate test scenario. In case of more high level test scenarious when deployment is required the user has to model the testing scenario in a similar manner like in the case of building processes using the facilities provided by ETICS framework. And the plugin mechanism could be used inside process for specific tasks. 24

Acceptance test INFSO-RI-223782 Until know we have for our GWT project • Local/Remote build scenario • Build scenario with unit and static tests and metrics calculation utilities • Deployment on test environment • Web service test scenario with coverage metrics calculation All these tests are code related tests. Missing: user acceptance tests. (‘Selenium’ is under investigation for this purpose. ) 25

INFSO-RI-223782 Transition to multinode – abstract workflow 26

Transition to multinode INFSO-RI-223782 27

Transition to multinode INFSO-RI-223782 28

INFSO-RI-223782 Transition to multinode – concrete workflow Deployment of the Registration webservice 29

INFSO-RI-223782 Concrete workflow Flow connectors of WA and Plugin Generator Service 30

INFSO-RI-223782 Concrete workflow Deployment of the WA and PG web service 31

INFSO-RI-223782 Concrete workflow Deployment of the WA and PG web service 32

Benefits of this scenario INFSO-RI-223782 Very quick deployment on the test environment („last-minute” developments can be put in production easily) Configuration parametres can be extracted easily as properties or environment variables – not a hidden knowledge of the system administrators Different configurations for different purposes (build, deploy, unit test, web service testing) Coverage metrics for web services help developers in identifying the ‘clien/server’ problems which unit tests can not provide Testing of web services in a „production” environment 33

Test Tool registration system INFSO-RI-223782 http: //lxetvm 0016. cern. ch: 8080/etics. Portal 34

Conclusion INFSO-RI-223782 • The mentioned scenario is considered to be the „marketing project” for 4 D SOFT. • It means, that this project will be used to show for possible customers the features that ETICS provide • In that way should be „perfect” from technical point of view 35