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

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

INFSO-RI ETICS Testing Services 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

INFSO-RI New ETICS Testing Services JRA2 tasks 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

INFSO-RI New ETICS test services JRA2 task 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

INFSO-RI ETICS does NOT provide 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 Deployment test scenario of the Test Tool Registration System 7

INFSO-RI ETICS Test system – main architecture 8

INFSO-RI Description of the scenario 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 Goal of the deployment scenario 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 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

INFSO-RI To sum up the scenario 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

INFSO-RI Modelling the environment in ETICS 12

INFSO-RI 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 In case of new configuration (communication) parameters – they should be added in the deployment script. 13

INFSO-RI Steps to be performed Building the packages The jars and wars are created and are copied into the stage dir. The initial configuration files (service.property, eticsPortalWA.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(eticsPortalWA) will be copied into the stage dir. (Everything needed for deployment is in the stageDir) 14

INFSO-RI Steps to be performed Deploying the packages Deploying of the components is done (from the stage dir deploys...) Deployment scripts for different configurations rebuildTestsystem.sh – main deploy script without WIKI rebuildTestsystemWiki.sh – main deploy with wiki deployEticsPortalWA.sh – main deploy without registration system restartTestSystem.sh – start/restart tomcat without deploying the war file 15

INFSO-RI Deployment settings For example in our case: REG_SYS_SERVER_NAME: SERVER_NAME: WF_DESIGNER_URL: 16

INFSO-RI Steps to be performed Deployment steps for the each component Stops the tomcat and disable firewall Deletes the necessary folders in the tomcat directory Copies the initial configuration files (service.properties, eticsPortalWA.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: or or....) 17

INFSO-RI Configurations 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

INFSO-RI Configuration for testing purposes org.etics.testsystem_build Profiles are set (subconfigurations, profiles ) : eticsPortalWA.build: checkstyle; findbugs; pmd; jccn; ckjm; pluginGenerationWS.build checkstyle; jdepend; findbugs; pmd; jccn; ckjm; pluginRegistrationWS.build emma; jdepend; findbugs; jccn; ckjm; cobertura; testSystemPortlet.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

INFSO-RI Web service test scenario 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 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 /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 ${reportsDir} test: ant emma.dist -f build-emma.xml; sh ${stageDir}/deployRegistrationWS.sh prepublish: publish: (Output: instrumented web service is deployed on tomcat) ( 21

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

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

INFSO-RI Conclusion 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

INFSO-RI Acceptance test 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 Transition to multinode – abstract workflow 26

INFSO-RI Transition to multinode 27

INFSO-RI Transition to multinode 28

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

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

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

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

INFSO-RI Benefits of this scenario 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

INFSO-RI Test Tool registration system 34

INFSO-RI Conclusion The mentioned scenario is considered to be the „marketing project” for 4D 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