}w!"#$%&'()+,-./012345<ya

Transcription

1 }w!"#$%&'()+,-./012345<ya Masaryk University Faculty of Informatics Automated Testing of the Component-based Web Application User Interfaces Bachelor thesis Juraj Húska Brno, 2012

2 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Juraj Húska Advisor: RNDr. Petr Ročkai ii

3 Acknowledgement I would like to thank RNDr. Petr Ročkai, the advisor of my thesis, for his help, comments and time spent helping me with this work. I am profoundly grateful to Bc. Lukáš Fryč for his guidance and support throughout my work. I would like to also thank Mgr. Marek Grác for his advices. My thanks go to my parents, my girlfriend and my close friends as well. iii

4 Abstract This bachelor thesis explores and describes modern trends in testing enterprise web applications. After the investigation, tools for automated testing of these applications are selected and compared according to maintainability, implementation of these tests and their usage in the systems of continuous integration. Based on the analysis, a high level application programming interface for using in testing the component based web application user interfaces is implemented. iv

5 Keywords software testing, abstract component model, high-level API, Web UI testing v

6 Contents 1 Introduction Testing of enterprise web applications Definition of testing Division of testing According to way testing is performed Manual testing Automated testing Benefits and drawbacks of both approaches According to depth White-box testing Black-box testing Gray-box testing According to scope Unit testing Integration testing System testing Continuous integration Key principles Problems Enterprise applications definition Enterprise testing approaches Other employed forms of testing Example of enterprise testing process Evaluation of the tools Criteria for choosing the tools examples Selected tools Arquillian Drone Geb The results Component Model Motivation for creating the component model Component based Web frameworks Model requirements Object Oriented UI Testing Patterns Page Objects vi

7 4.2.2 Component Objects Implementing the Component Model Employed Java technologies Java Reflection Java Dynamic Proxies Java Generics Service Provider Interface Integration with existing Frameworks WebDriver Arquillian Drone Component Case Studies Autocomplete component Table component Calendar component Real Deployment Showcase application Functional Tests Conclusion A Example of UI test verbosity B Factory class and its methods C Test enricher D Sequence Diagram of Autocomplete Component E Sequence diagram of Table Component F Sequence Diagram of Calendar Popup Component.. 76 G Omitted Arquillian test configuration H Manual for building showcase application I Functional test without using of Component Model.. 79 J Functional test with using of Component Model K Contents of Attached CD vii

8 1 Introduction Testing software is an important part of development of all applications. For enterprise applications, however, it is inevitable. This is due the fact that a development of enterprise applications is costly and timeconsuming, but carefully choosing improved testing methods leads to cheaper development and maintenance [1]. At present time, an increasing number of applications, either enterprise or standard, is focusing on running in browsers, on desktops and mobile devices. This is happening because a web application is easier to distribute. The biggest benefit is that there is no need to create a separate application for each platform. The rule "write once, run everywhere" can be applied. Testing the functionality of these applications is therefore highly focused on User Interface (UI) testing. One way of reducing the cost of developing and testing applications is automated testing. Present development of scripts for automated UI testing, however, suffers from many drawbacks. The way, in which tests are written, is too on low level and therefore verbose, and also tightly coupled with a specific implementation details of applications. Therefore, often a small change in the application leads to many changes in tests, and thus provides more opportunities to introduce errors into the test. Development and maintenance of such tests is therefore expensive [2]. This thesis is aimed at exploring and describing modern trends in testing enterprise web applications in the first phase, then after the investigation, it is aimed at selecting tools for automated testing of these applications, comparing them according to maintainability, implementation of these tests and their usage in the systems of continuous integration. This analysis should provide high level application programming interface (API) for use in testing the component based web application user interfaces. The work s goal is to improve readability of tests and therefore also the maintainability by employing the created API in testing of enterprise applications. An API is successfully adapted by users when it provides a clear contract for each component; it should be easily employed; it shall evoke confidence in users that the authors are able to maintain the API, and 1

9 1. Introduction should build on already well-known projects. These are the objectives that the API focuses on, as these are also the points that are considered when deploying a new dependency in enterprise solutions. The second chapter of thesis analyses the different types of testing enterprise applications, and the third chapter compares selected tools for automating UI testing. Integration and implementation of the created API is described in Chapter 4. This chapter also describes the selection of three major components, for which I created the API and their implementation and their use in real-life example. Benefits of using the created API are described in chapter 4 as well. 2

10 2 Testing of enterprise web applications 2.1 Definition of testing Testing software is any activity aimed at evaluating an attribute or capability of a program and determining that it meets its required results [3]. Testing approach depends on the software development life cycle model 1, and thus it needs to fit the model being used for the tested project. However, a common objective of all approaches is to find the problem as soon as possible, to reduce the cost of fixing it later [4]. 2.2 Division of testing The attributes of testing, like how big pieces of AUT (application under test) we are testing, or what knowledge about AUT the tester 2 has, and the way testing is performed, divides testing activities into several groups of types According to way testing is performed Test can be executed manually by humans or automatically by computers. Manual testing It involves manual tasks, such as: setting up the test environment, executing the tested functionality, collecting and reviewing the results and recording found issues. This process can be done by following a test plan or, alternatively, by exploratory testing [5]. Following a test plan Test plan is a formal list of steps needed to be done to test an application functionality. According to IEE The process of creating a software product from its initial conception to its release [4]. 2. The person who either performs tests, or who develops them. 3

11 2. Testing of enterprise web applications 2008 [6] it should contain among other things: a test plan identifier, an introduction, test items, the features to be tested, the features not to be tested, an approach, item pass/fail criteria, and other prerequisites. Because it uses a predefined plan to test an application, it does not depend tightly on tester s skills. On the other hand, it can be more time consuming to create and maintain test plans. Exploratory testing It is not tied with any test plan, hence requires less time for preparation, and can discover important problems quickly. The problems are that it is harder to reproduce any discovered problems in later application development phases, and exploratory testing also tightly depends on tester skills. Automated testing Execution of tests without human intervention can be defined as automated testing. Automated tests execution includes, however, other prerequisites [7]: Ability to run a subset of all tests. Automatic set-up and record environmental variables. Running the test cases. Capturing the results. Comparing actual and expected results and highlighting the differences. Analysing the results and processing them in a comprehensive and clear way. Benefits and drawbacks of both approaches Both manual and automated testing approaches have benefits as well as drawbacks. An application context should help with deciding which one is more suitable. The context includes following: how big the application is, how big is the budget of the project, or when it should be released. 4

12 2. Testing of enterprise web applications Manual testing benefits The set-up time is shorter in comparison to automated testing. Moreover, it is possible to easily test manually during all development phases, since there are no constraints on what is suitable to test manually and what is not. Manual testing drawbacks Repetitive and mundane tasks performed during manual testing can lead to inaccurate or incorrect results. The execution of tests is also slower than tests executed by a computer. Automated testing benefits and drawbacks Automated testing has benefits for bigger projects, since the initial cost for automation, and test maintenance can be high. Some of the benefits and simultaneously drawbacks are [1]: Automation helps to eliminate human errors - some of the mistakes which are made during manual testing can be reduced. This concerns errors which were incurred by performing a long list of mundane activities. Automated tests are faster than manual testing - this is considering only the actual execution of tests, it does not tell anything about reviewing the results and then possibly fixing the broken test. Because the execution is faster, the results are accumulated faster too, hence the tester needs to review more results in a shorter amount of time. Automation can lead to cost reductions. To claim that automation can reduce costs, we need to firstly realize, what is included to overall automation costs [1]: The cost of implementing a test harness 3. The cost of learning how to use the harness. The cost of developing automated tests. The cost of maintaining the tests as the product change. 3. Also called test driver, a tool used to execute and control tests. 5

13 2. Testing of enterprise web applications The cost of reviewing the test results. This overall cost needs to be added to the cost of the remaining manual testing costs, as some manual testing is still likely to be required, especially when testing UI. This sum need to be compared to the sum of manual testing only According to depth Next chosen division is according to the attribute which reflects the depth of tester insight into the tested application [4]: White-box testing It is also known as clear box testing, and denotes technique, when tester knows the underlying implementation of an application, so he can decide how to develop the tests according to this knowledge. It is used mainly for checking small parts of an application, for example their database transactions. Black-box testing It indicates the way of testing, where the tester does not know the details of how the AUT works. An output of the tested action is important, but not how the action was done. It is used mainly for testing of bigger, already implemented parts of the AUT functionality. Gray-box testing It has both black-box and white-box testing characteristics. An example of this is testing of functionality of web applications, because to perform this type of testing, the knowledge of web page structure is required, and simultaneously it is not important how the tested functionality was performed. 6

14 2.2.3 According to scope 2. Testing of enterprise web applications The last 4 described attribute is a scope [8] of the testing. The scope denotes the size of the tested parts, or more specifically, indicates the number and the size of the parts, needed to achieve a tested functionality. It also stands for the development cycle 5 of the application it is currently in, when the tests are written for it. The motivation behind separating pieces which should be tested, is that testing pieces in isolation allows identification of core fault easily. Testing pieces of the application would lead to avoiding many surprises when testing the entire product. In other words, when the fault is found in an unit, then probably that unit is defective, when the fault is occurring in two integrated units, it has to be related to how units interact [4]. Unit testing A unit is the smallest testable piece of software which can be compiled and put under test harness [10]. Unit testing (sometimes module testing [4]) is typically performed as white-box testing (see section 2.1), because the tester needs to know the code which he is going to test [11]. Scope of unit testing is narrow, in other words, it should verify small parts of the entire application. An example of unit testing can be testing of an unit which is responsible for computing factorial of a natural number. Unit tests are usually written by developers of the application, or framework. The tests should be developed and executed in prior to or during the implementation of the modules [11]. It is not necessary to wait with testing of units until all units are implemented because they should not have dependencies on each other. 4. There are more attributes for dividing testing methods into groups, see [8] for basic overview. 5. For example linear development methodology called Waterfall recognizes these development phases: Initial Investigation, Requirements Definition, System Design, Coding and Testing, Implementation, Operation and Support [9]. 7

15 2. Testing of enterprise web applications Formally it is standardized by, for example, IEEE Standard for Software Unit Testing 6, which describes the exact process which should be performed, its inputs and outputs. When comparing unit testing with testing of bigger parts of AUT, unit tests are often easier to develop, as they are more straightforward, and have less dependencies. Also running unit tests is less timeconsuming than running other types of tests. The drawbacks come from the fact that with unit testing, we cannot verify that an application is entirely flawless, even when we will be testing all units. The problem is, that they are tested separately, and after they will be integrated, some critical issues can arise. Writing unit tests is laborious, cumbersome and often difficult task. It is because the testing code is written at low level of abstraction, therefore, it can be tedious to introduce a change in tests to match the code under test changes [12]. Hence complete automation of unit testing is not only feasible but also effective [13]. There are several tools which leverage unit testing and provide integration with IDE (Integrated Development Environment) 7. In Java environment, the most used frameworks are JUnit 8 and TestNG 9, which provide almost the same functionality nowadays, mainly the ability to annotate a method with proper annotation to mark which method is a test method, and then collecting results in some standard format, to easily interpret them with IDE. Mock versus real objects testing "Not all code is self contained" [16], in other words, real applications have a lot of dependencies. Unit tests are intended to test as much independent modules as possible. This is, however, very hard to achieve in real world applications. 10 The tester then has basically three options: test with real objects; 6. ANSI/IEEE Std , standard/ html. 7. An application which provides environment for development, debugging and more. An example is Eclipse [14] or NetBeans [15]. 8. JUnit, 9. TestNG, Applications not created with purpose of learning some technology, but to have real addition. 8

16 test with mock objects; test with stubs. 2. Testing of enterprise web applications Real objects Testing with real objects would mean to use some of the dependencies the tested unit has. But this means relying on the fact that used dependencies are correct, that they are tested somewhere else [16]. Suppose the listing import java. u t i l. L i s t ; 2 import java. u t i l. ArrayList ; 3 4 import org.my. foo. Equipment ; 5 6 public class Garage { 7 8 // w i l l r e turn f a l s e i f t h e r e was corrupted t o o l. 9 public boolean checktoolscondition ( List <Equipment> t o o l s ) { int numberoftools = t o o l s. s i z e ( ) ; for ( int i = 0 ; i < numberoftools ; i ++) { 14 boolean good = ( t o o l s. get ( i ) ). checkcondition ( ) ; i f (! good ) { 17 return f a l s e ; 18 } 19 } return true ; 22 } 23 } Listing 2.1: Example of using third party dependency to implement our service. On lines 9, 11 and 12, our artificial 11 example depends on a third party service, provided by imported dependencies of classes List and ArrayList. When testing this service (Listing 2.2, line 17), we will be also testing that these dependencies are working properly[16]. 11. The intention is to just illustrate the use of Mock objects. 9

17 2. Testing of enterprise web applications 1 import java. u t i l. L i s t ; 2 import java. u t i l. ArrayList ; 3 4 import org.my. foo. Equipment ; 5 6 public class TestGarage { 7 9 public void testchecktoolscondition ( ) { 10 Equipment axe = new Equipment ( " axe " ) ; 11 axe. s e t C o n d i t i o n ( ConditionEnum.BAD) ; List <Equipment> t o o l s = new ArrayList<Equipment >() ; 14 t o o l s. add ( axe ) ; Garage garage = new Garage ( ) ; 17 boolean r e s u l t = garage. checktoolscondition ( t o o l s ) ; a s s e r t F a l s e ( r e s u l t, " The method did not d i s c o v e r corrupted t o o l! " ) ; 20 } 21 } Listing 2.2: Example of testing with real objects. And that was not our intention. since we wanted to test only Garage behaviours, isolated. Indeed, this is only an contrived example, but in real world applications, reliance on the correctness of third party dependencies can lead to bugs and unit test failures caused by malfunction not of the Garage class itself. This kind of problems is often hard to find and reproduce, and therefore should be avoided somehow. Mock objects One of the solutions for this is to use mock objects instead of real objects. Mock objects encourage testers to write better structured tests with reduced dependencies. It is a technique used in TDD (Test-Driven- Development 12 ) [18]. In other words, tester will mock the services provided by other than tested class. He will define the exact behaviour the services should have, 12. Software development methodology which among the other things, encourage to write tests at first, then implementation [17]. 10

18 2. Testing of enterprise web applications and by this, he does not suppose that the services works as expected any more. It does not have to be used only in TDD, but in other testing methodologies as well. In Java environment, there are several mocking frameworks. Listing 2.3 demonstrates creation of a mock object in Mockito 13 for dependencies from Listing import java. u t i l. L i s t ; 2 import java. u t i l. ArrayList ; 3 4 import org.my. foo. Equipment ; 5 6 public class TestGarage { 7 9 public void testchecktoolscondition ( ) { 10 Equipment axe = new Equipment ( " axe " ) ; 11 axe. s e t C o n d i t i o n ( ConditionEnum.BAD) ; List <Equipment> t o o l s = Mockito. mock( L i s t. class ) ; 14 when ( t o o l s. get ( anyint ( ) ) ). thenreturn ( axe ) ; 15 when ( t o o l s. s i z e ( ) ). thenreturn ( 1 ) ; Garage garage = new Garage ( ) ; 18 boolean r e s u l t = garage. checktoolscondition ( t o o l s ) ; a s s e r t F a l s e ( r e s u l t, " The method did not d i s c o v e r corrupted t o o l! " ) ; 21 } 22 } Listing 2.3: Example of creating Mock object for third party dependencies. According to [18], after a revision of the initial definitions of Mock objects, testers are encouraged to mock only dependencies they own. In our example we should mock the Equipment class instead of List interface Mockito - Java Mock framework, more info at mockito/. 14. The more information about why and the proper solution, can be found at [18]. 11

19 2. Testing of enterprise web applications Stubs Another solution for testing units without their external dependencies is to replace these dependencies by stubs which are real objects developed against defined interface to substitute functionality of real implementation. The difference between stubs and mock objects is that stubs need to have predefined behaviour, while behaviour of mock objects is defined at runtime Integration testing Next level after testing units, is testing of integrated units, so-called integration testing (sometimes product testing [11]). These units are considered to be flawless, as their unit tests are passing without problems, and we want to verify that aggregating of these components cannot create a problem. An example of such problems can be incorrect return value of a method call, or insufficient validation criteria [10]. A special kind of integration testing is application programming interface 17 (API) testing. It is used, for example, to validate REST 18 API, or an API of web components, which is done for this thesis. Integration testing can be performed as both white-box and black-box testing (see section 2.2.2). It should be performed by an independent test team, and can begin as soon as enough of the tested units are implemented, or when units need to integrate with components outside of system, for instance with database. During this phase, all customer environment variations should be considered and tested [11]. Meaning that, for example, all supported Operating Systems or browsers should be combined and tested. Automation of integration testing is even more difficult than unit testing automation. It is because of integration-level complexity, which is firstly caused by complicated initial system set-up. To test integration 15. More information about differences between stubs and mock objects can be found at An example of a stub created for this thesis is AbstractComponentStub, which can be found in the api module. 17. API, a specification intended to be used as an interface for communicating among software components [19]. 18. REST, 12

20 2. Testing of enterprise web applications issues whole system need to be set to an initial state. Secondly it is caused by problematic retrieving of tests results, suppose for example retrieving results from testing of database transactions [20]. The challenge for web applications is that they often need to run in an application container in order to work. The application container, used mainly in Java EE 19, is an application which provides various services for the AUT, such as handling concurrent access to the application, management of application s dependencies, or providing database connections [21]. In such environment, there are application dependencies and services which are often provided by a container. To provide this functionality for tests, a tester has basically two options [22]: mock the application dependencies provided by a container as described in subsection 2.2.3; or to deploy tests into container, and perform in-container testing. Mock integration environment Using Mock objects brings an uncertainty to our tests, because we cannot be sure that the application will behave the same in the real environment, in this case, in the container. To avoid this uncertainty, in-container testing can be employed. On the other side, mocks allow us to run tests faster than in-container, since they do not have to take unnecessary actions like parsing configuration of the application. In container testing This type of testing involves deploying our tests to the container, execute them, and collect the results remotely. It is also a typical example of gray-box testing (section 2.2.2), because application container provides a logic which implementation is unknown. Although this brings a significant advantage of having the dependencies being provided by the container, it also brings another layer to our testing infrastructure [22]. This layer represents a lot of new code lines, or used dependencies which would manage shutting down the application container, packaging and deploying the AUT, executing tests and other. 19. Java Enterprise Edition, javaee/overview/index.html. 13

21 2. Testing of enterprise web applications Hence, in-container testing pose problems with test readability and maintenance, since the tester is not responsible for underlying implementation. System testing Several units aggregated into one make a component; several components integrated into one make one big component, called system. Testing of such big component is called system testing [10]. It is aimed to reveal problems which can be exposed by only testing the entire integrated system or a major part of it. An example can be an error exposed by different communication network protocol, used for communicating with other components or systems [11], or in case of web applications, testing of user interfaces. It is an example of black-box testing (section 2.2.2) and it is the third phase according to target testing, during which the test team should replicate application user environment. It should begin after all components functionality was implemented. Functional Testing It is similar to system testing, because it is a kind of black-box testing (see the section 2.1), where the user point of view is taken into account. Meaning that, the application is subjected to various inputs, and its outputs are the subject to testing, because they need to conform with specified behaviour [10]. The performance of functional testing on a web application, would mean that a tester should verify functionality of all pages, all components against various inputs. A simple example can be verification that, clicking on the button would cause expected action. Because testing of the web page functionality relates to testing of the UI (User Interface), it has the same properties, both advantages and disadvantages. One of the advantages is that it is quite clear what to test and how to test, therefore it can be performed by less technically trained people. Automation UI testing problems Testing of User Interface has some specifics. One of them is large basis of possible inputs, and interactions which an user can perform with a web page. 14

22 2. Testing of enterprise web applications Manual testing is, therefore, quite error-prone, as a tester can easily forget to test some of the functionality from the specification, as he is doing a repetitive task. It is also very time consuming, therefore expensive. One of the solutions is exploratory testing (section 2.2.1). These are the reasons that it is a good practice to have parts of the functional testing of the web applications automatized. As section described, one of the requirements to have tests automatized, is to have defined a script which will instruct the particular testing driver, what interactions with a tested web application need to be done. By this, the execution of the tests can be repeated. This script can be assembled in two ways, usually by a tool integrated with a browser. Tool captures user interactions with the web application, therefore, they can be repeated later. Second way is to define the script programmatically, which means writing it with use of calling methods from a testing tool API. An example of the programmatic script is in Listing public class TestNavigationOverPages { 2 3 private WebDriver d r i v e r ; 4 6 public void testpopup { 7 d r i v e r = new F i r e f o x D r i v e r ( ) ; 8 9 d r i v e r. get 10 ( " http : / / l o c a l h o s t :8080/ mytestapp/ index. html " ) ; d r i v e r. findelement (By. id ( " button " ) ). c l i c k ( ) ; WebElement popup = d r i v e r. findelement 15 (By. xpath ( " // span popup ] " ) ) ; a s serttrue ( popup. i s D i s p l a y e d ( ), " The popup should be displayed, when c l i c k i n g on the button! " ) ; 18 } 19 } Listing 2.4: Example of programmatic script for testing simple web application page. 15

23 2. Testing of enterprise web applications When considering the Listing 2.4, it is noticeable that it exposes some of the programmatic UI testing deficiencies 20, such as: Tests maintenance; Inability to test every aspect of the application Reliability of tests Non-effectiveness for some agile development methods Re-usability of the tests Slow speed of test execution Tests maintenance - there is a hard-coded structure of tested web page, on the lines 11 and 13. Should this structure change in the future, the test will need to be changed as well. When considering 10,000 tests for an application, this low level approach would mean increased costs for tests maintenance. The best approach would be if the test class could be abstracted from this structure. Another problem is using of simple String objects, as a method parameters, instead of type-safe 21 way, which would include usage of objects other than String, and therefore reflecting on their purpose. This was just a very simple example of test, real UI tests tend to be very verbose (see the appendix A) These problems are more noticeable when maintaining several tests, especially for an application which evolves. Inability to test every aspect of the application - the script is just testing that after clicking on the button, a pop-up is displayed. Whether the pop-up was rendered correctly, that is, whether it is in the correct place, with correct skin, and with a proper size would be very difficult programmatically. Therefore, some of the web application aspects still need to be tested manually The deficiencies are not caused by tool selecting, they are very common for all such tools. 21. It is a way of forcing a developer to use some particular type of the object, to ensure discovery of type errors at compile time. 22. There are currently some tools which leverage some of the visual testing burdens, but they can not still fully replace a human. 16

24 2. Testing of enterprise web applications Reliability of tests - tools which use JavaScript browser engine to instruct browser what interactions are need to be done for particular test, are quite unreliable. Each browser has different JavaScript engine, and testing on various browsers means writing browser-specific code for some tests. This is, again, another load for test maintenance. Non-effectiveness of some agile development methods - the fact, that tests hold information about implementation structure, causes that they need to be written after the implementation of tested functionality. Hence, they are quite unusable with agile techniques like TDD [23]. Re-usability of the tests - many parts of the tests are repeated in other tests, because tested functionality requires common actions to be done before the actual testing. Tests tend to be slow to execute - the execution of simple test can be measured in seconds. When running the whole test suite, it can be increased to days to finish. This is quite a big problem in Continuous Integration (CI) (see section 2.3) environment. 2.3 Continuous integration Continuous integration has its roots in XP (Extreme Programming), which is agile 23 software development methodology, aimed to improve software quality, while reducing time needed to respond to customer s constantly changing demands [24]. The software quality is improved by reducing the integration (see the section 2.2.3) risk [25]. That is the risk of testing on the integration level in the end of the product life cycle development, instead of testing continuously to discover and fix possible errors as soon as possible. Therefore, integration testing is feasible not only for integration testing, but as well as for unit testing and system testing Key principles To achieve better software quality, CI process has to duly observe following key principles [25]: 23. Agile software development methods using practices of incremental a iterative development. 17

25 2. Testing of enterprise web applications Application code should be maintained in the code repository. Build and tests of the application should be automated. Code changes should be delivered to the code base every day. Each delivering of the code should trigger project build and testing process on dedicated machine. The building and testing should be as fast as possible. Test should be run in the production environment. Results should be clearly visible and authors of the code delivery should be notified that their code delivery might cause failure. The latest version of application should be easily accessible, and this process of releasing the application should be automatized Problems The benefits which CI brings outweigh the disadvantages, but they need to be considered as well. The most critical are: Initial investments into hardware, that is usually dedicated machine with CI tool running on it and its slaves on which the actual CI build and testing is performed. The cost could be partially limited by virtualization of some of the machines. 24 Security vulnerabilities need to be taken into account, because an attack to CI system can mean disclosure of confidential information or system shutdown, which can have a negative impact on application development process. Tests need to be automatized, which can extensively increase the overall development expenses. 24. Virtualization is a creation of virtual hardware platform, or operating system, etc. 18

26 2. Testing of enterprise web applications 2.4 Enterprise applications definition Enterprise applications are software products designed to facilitate cooperation and coordination of work across the enterprise. It includes the interconnection of core business processes like sales, accounting, finance, human resources, and other. Very often, it also provides interfaces to connect customers, suppliers and other business partners to that system [26]. The more functionality they provide, the more complex they become. There is also stress on proper development process to avoid unnecessary costs and to provide product with sufficient quality. As they often perform work with important data, which need to be processed in real time, the focus is on other important aspects, and challenges as well, like namely [27]: Performance; Data persistence; Accessing data concurrently; Numerous UI screens; Integration with other enterprise applications; Security. Performance - is important for all kinds of applications but for enterprise software, it is often crucial, as their performance can significantly influence the usability and the responsiveness to stimuli. These performance deficiencies may have an impact on customers, therefore, can cause significant monetary loss. Data persistence - enterprise applications works with a lot of data which need to persist not only between multiple runs of the application but several years. The system has to be adaptable to the changes of the data structure as new requirements for the new system functionality emerge. Accessing data concurrently - especially for Web enterprise systems, there is a large number of users, who access the system concurrently. 19

27 2. Testing of enterprise web applications Therefore, there has to be reliable mechanism to ensure, that this concurrent access is not changing the data in a way that causes errors. Numerous UI screens - a lot of data means a lot of distinct UI screens that handle this data. They need to be presented in many various ways, for all kinds of users, which can bring a lot of error-prone lines of code. Integration with other enterprise applications - enterprise applications need to collaborate with other applications. The problem is, that these applications are often built to run in different environments, written in other programming languages. This, again, introduces a lot of error-prone places in the application code. Security - because enterprise applications control money and resources, any security violation can cause, for instance, loss of confidential or classified data, or other significant financial loss [28]. 2.5 Enterprise testing approaches In addition to forms of testing described so far, not only the enterprise software employs other important forms of testing [29] Other employed forms of testing The first described is Alpha testing. It is performed by the internal development team or quality assurance team in the controlled environment, typically dedicated labs with an environment simulating customers requirements. It is aimed to discover deployment and workload issues, which need to be captured before the final release. Acceptance testing is utilized for customized software and applications, designed for particular customer, rather than general applications for broader base of users. The customer chooses a user who will validate the application according to its specification. Installation testing validates compatibility with hardware platforms, that is, whether the application is portable to different hardware and software platforms if this is requested by the customer. The portability is the ability to run the application on 20

28 2. Testing of enterprise web applications different hardware and software platforms without additional changes required from the end user of application. Stress testing is used to simulate abnormal behaviour in a program by considering situations that cause abnormal end of the program, to create a benchmark of software stability. Smoke testing is aimed to test the code after the introduction of a new code, to confirm that new changes do not compromise the integrity of the product. Smoke tests should be fast to execute, because they are often used to quickly validate the integrity of the product, before deeper testing takes place. Usability testing measures the simplicity of using the application. In case of applications with GUI (Graphical User Interface), these interfaces are the subject of examination measuring for example user accuracy or application response times Example of enterprise testing process To meet the requirements from section 2.4, enterprise software needs to be tested in a proper way. To test the application properly, there is a need to test every feature of the product on every possible configuration [11]. This can be, however, very exhausting process. Therefore, there is a demand for efficient testing. We need to find an approach which enables finding most of the problems, for as reasonable cost as possible [11]. Hence, a big emphasis is put on the automated testing. In other words, what can be automated is automated, the rest is done manually. CI is another employed technique, into which a lot of funds is invested. It is usually the most important part of the testing structure, thus is critical for enterprise products. Figure 2.1 shows an example of enterprise testing process time-line [11] [29]. First Milestone is a term for first development milestone, when the application is in the state, when the system testing can begin. Code freeze is the state when no additional code changes are allowed. 21

29 2. Testing of enterprise web applications Figure 2.1: An example of enterprise testing process time-line. 22

30 3 Evaluation of the tools 3.1 Criteria for choosing the tools examples The aim was to choose several tools for automated testing of the enterprise web applications and consequently compare them according to maintainability, implementation of these tests and their usage in the systems of continuous integration. From the variety of web UI automation testing tools [30], I choose and concentrated mainly on tools which are suitable for enterprise usage. That means, they have to provide cross-browser testing ability. In other words, they have to support all major browsers, which are currently Firefox, Internet Explorer, Safari, and Google Chrome 1, on the major Operating Systems platforms (Linux, Windows, Mac). The selected tools have to be able to provide programmatic way of creating test scenarios as we believe, this would be the way to enable further maintainability improvements and CI integration. Test automation is very similar to software development, therefore, the same logic can be applied [2]. Next requirement was that the selected tool has to be open sourced 2, which allows use of this tool as a base for the created component model. The tool has to be enabled for testing rich web applications. In other words, it has to support testing of Ajax-based web sites. I focused on projects with well based community behind them, as enterprise solutions usually cannot afford to invest money into unstable or small-scale projects. The best way was to choose project with a financial supporter behind it, as for example a big software company which either employs the framework developers or provides other support for it. 3.2 Selected tools According to criteria for selecting from section 3.1, I chose following frameworks: 1. See reference [31]. 2. Open Source, 23

31 3. Evaluation of the tools Arquillian Drone [32] Geb [33] Arquillian Drone Arquillian is a testing platform that enables developers to create automated integration, functional and acceptance tests. Its main focus is on separating the test and the runtime, so a tester can concentrate on test logic rather than on managing the runtime from the test. This brings lot of benefits for an in-container testing 2.2.3, while Arquillian is eliminating the burden connected with it. Among other things, it manages following: The life cycle of the application container. Packages test cases and other dependencies into an archive. Deploys this archive to the containers. Enriches the test case by Dependency Injection (DI). 3 Executes the test inside or against the container. Collects the results remotely and returns them for reporting. I chose Arquillian extension called Drone. It inherits all aspects of Arquillian, and furthermore adds support for managing life cycle of browser. The list of supported browsers begins as it is required with the major used browsers. Since Arquillian was created to be highly extendable it also enables to add support of any desired browser. Drone is not a driver itself, it integrates with existing drivers, such as Graphene [34] and automation tool Selenium 2 4 which is a union of Selenium 1 and project WebDriver 5. Graphene is a wrapper for Selenium, that was created to provide type-safe way of using the Selenium API, and other tools for testing an 3. DI, 4. Selenium 2, 5. Selenium, 24

32 3. Evaluation of the tools Ajax enabled web pages. An Arquillian project is configured via Apache Maven 6 build system. An example of a test written in Arquillian Graphene for an artificial application, can be found in Listing 3.1. It is shortened, as for example Java imports statements are left to keep it readable. Also the method for deployment of AUT is left. The example of this deployment method can be found in appendix G, where AUT is assembled with the use of ShrinkWrap 7 project. In following listing, line 1 indicates that it is an Arquillian test, line 3 and 4 is DI for context root, that is, the root part of the URL which will be accessed in order to load the application in the particular browser. Line 6 and 7 injects the driver which is in this example Arquillian Graphene, via which the browser is instructed. On the lines 9-25 a test is declared that simply fills some characters in the input, triggers an Ajax action and asserts that the generated output is the same as the inserted characters. 1 public class TestMyApp extends A r q u i l l i a n { 2 4 protected URL contextroot ; 5 7 protected AjaxSelenium selenium ; 8 10 public void testajaxinput ( ) { selenium. open ( URLUtils. b u i l d U r l ( contextroot, " /myapp/ i n t e x. html " ) ) ; S t r i n g t e s t S t r i n g = " Test S t r i n g " ; JQueryLocator input = jq ( ". myinput " ) ; selenium. typekeys ( input, t e s t S t r i n g ) ; 19 guardxhr ( selenium ). f i r e E v e n t ( input, Event.KEYUP) ; JQueryLocator ajaxoutput = j q ( ". myoutput " ) ; 6. Apache Maven, 7. ShrinkWrap, 25

33 3. Evaluation of the tools S t r i n g actualoutput = selenium. gettext ( ajaxoutput ). trim ( ) ; 24 a s s e r t E q u a l s ( actualoutput, t e s t S t r i n g, " The output generated by Ajax i s not c o r r e c t! " ) ; 25 } 26 } Listing 3.1: Example of test written in Arquillian Graphene Geb Geb is the second chosen tool. It also uses WebDriver internally together with JQuery 8 content selection. It is similar to Arquillian Drone in terms of cross-browser testing and ability to test asynchronous pages. The differences from Arquillian Drone is that the test scenarios are written in Groovy. And it also lacks the Arquillian support for management of test life cycle. Apache Maven can be used for building. Support for Gradle 9 and Grails. 10 is added. An example of test written in Geb is shown in Listing 3.2. The test scenario is the same as in listing 3.1. On line 2, it is accessing the URL on which the tested application is deployed, line 4 ensures that the tested page was completely loaded. On line 6, it is using JQuery like syntax for locating of element with class myinput, and consequently the found element is filled with value Test String. Line 8 asserts that the element with class myoutput was updated with expected value. 8. JQuery, 9. Gradle, Grails, 26

34 3. Evaluation of the tools 1 Browser. d r i v e { 2 go " http : / / l o c a l h o s t :8080/myApp/ i n t e x. html " 3 4 a s s e r t t i t l e == "MyApp" 5 6 $ ( " input ", class : " myinput " ). value ( " Test S t r i n g " ) 7 8 waitfor { $ ( " div ", class : " myoutput " ). t e x t ( ) == " Test S t r i n g " } 9 } Listing 3.2: Example of test written in Geb 3.3 The results After the evaluation I would like to single out Arquillian Drone. There are several reasons for it. The first would be the Arquillian container management support which gives us a great tool to use in CI. Geb is also supported in CI. However, lot of functionality has to be implemented by the user to obtain the same result as with Arquillian. Arquillian is also easily extendable which gives us an opportunity to integrate our project with Arquillian Graphene later on. It also supports so called extensions which will help us to enhance usability of our created API. When considering the listings 3.1 and 3.2, at first glance it is noticeable that Geb example is less verbose, however, it does not provide the users with the functionality that Arquillian Graphene does, for instance the way how Graphene ensures that an Ajax event was fired (line 19). Another advantage of Arquillian Graphene tests is its type-safety. Possible flaws of code lines in JQuery syntax can be only found at runtime. This makes Arquillian Graphene tests more robust and therefore, more suitable for enterprise environment. It also enables the users to encapsulate the components in more readable way, hence better maintainable way, which will be useful later in API creation. 27

35 4 Component Model A component is a basic unit of the component-based Web frameworks (section 4.1.1). That is, for instance a calendar component. A graphical representation of the calendar component can be found in the figure 4.1. The term component model is used for the purpose of this thesis as a term for referencing an abstract API an its implementation, that was created for this thesis. Figure 4.1: Calendar component - RichFaces implementation. 4.1 Motivation for creating the component model Users of RichFaces framework (section 4.1.1) demand a way to easily test their enterprise applications. A component model was created to help them. The model encapsulates behaviour of all RichFaces components. These components will be then used in functional tests, to enhance tests maintainability, by encapsulating the structure of HTML code for particular component at one place. This way we could avoid code repetition and incidental details [2], which are the main inhibitors to introduce a change in the software. The idea was, instead of writing tests like demonstrated in Listing 4.2, write tests similar to the test demonstrated in Listing 4.1. Both tests on listings verify simple test scenario, where setting the current 28

36 4. Component Model date to the calendar will be correctly reflected in the input for that calendar. Note the differences: whereas in the first example the structure of the web page is hard-coded in the test, the second example uses services of calendar component which encapsulates that structure to achieve the same functionality. This way it is more visible what the purpose of test is. Furthermore, the more readable the code is, the better maintainable it is. 1 public class TestCalendar { 2 xpath = " // div rootelement ] " ) 4 RichFacesCalendar c alendar = new RichFacesCalendar ( " locatordeterminingcalendar " ) ; 5 7 public void testajaxinput ( ) { 8 Date expecteddate = new Date ( ) ; 9 10 c a l e n d a r. show ( ) ; 11 c a l e n d a r. settoday ( ) ; Date actualsetdate = c alendar. getsetdate ( ) ; checkthatdatesaresame ( expecteddate, actualsetdate ) ; 16 } 17 } Listing 4.1: Test for RichFaces calendar Arquillian, using component model. 1 public class TestCalendar { 2 3 protected JQueryLocator imgwhichinvokesthecalendar = jq ( " img. r f cal btn " ) ; 4 protected JQueryLocator applybutton = jq ( " div [ o n c l i c k = c l o s e ] : c o n t a i n s ( Apply ) " ) ; 5 protected JQueryLocator todaybutton = jq ( " div [ o n c l i c k =today ] : v i s i b l e " ) ; 6 protected JQueryLocator calendarinput = jq ( ". r f cal inp " ) ; 7 29

37 4. Component Model 9 public void testajaxinput ( ) { 10 selenium. c l i c k ( imgwhichinvokesthecalendar ) ; waitgui. f a i l W i t h (new RuntimeException ( " Calendar was not opened! " ) ) 13. timeout (1000) 14. u n t i l ( e l e m e n t V i s i b l e. l o c a t o r ( todaybutton ) ) ; selenium. c l i c k ( todaybutton ) ; 17 selenium. c l i c k ( applybutton ) ; waitgui. f a i l W i t h (new RuntimeException ( " Calendar was not c l o s e d! " ) ) 20. timeout (1000) 21. u n t i l ( elementnotvisible. l o c a t o r ( todaybutton ) ) ; Date expecteddate = new Date ( ) ; 24 Date actualsetdate = parsedatefrominput ( calendarinput ) ; checkthatdatesaresame ( expecteddate, actualsetdate ) ; 27 } 28 } Listing 4.2: Test for RichFaces calendar in Arquillian Graphene. Moreover this API does not have to reflect only on specific implementation of UI components, it can be transformed to provide unified API for various UI component libraries. These libraries can be collectively called component based frameworks Component based Web frameworks In the Java environment, component based frameworks, also known as a pull-based architectures, duly follow the MVC (Model-View-Controller) 1 pattern. As opposed to the action-based architectures 2 these frameworks start 1. MVC is an architectural pattern which separates an application into three main components: the model(business logic), the view (user interface), and the controller (user input) [35]. 2. Action-based (push-based sometimes), since they use actions that do required processing and then push the data to the view layer, examples: Spring MVC, Struts [36]. 30

38 4. Component Model with the view layer by providing set of core components which pull results from multiple controllers 3 as needed. [36] This means that, the components are managing the requests on their own, they do not need the developer to implement various interfaces to achieve the desired functionality. Examples of such frameworks are: JSF (Java Server Faces), Tapestry, Wicket, GWT (Google Web Toolkit), Vaadin as well as Stripes. Component oriented 4 frameworks can be identified also in other environments apart from Java. For instance ASP.NET Web Forms is a framework which also provides set of components for which the component model can be created. The last example of the environment where Web components play a significant role is JavaScript environment, an example is the jquery UI framework. All above mentioned frameworks have one important characteristic in common: each component has predefined the HTML mark-up code which is rendered on the client side (browser) and also the JavaScript sources which are either included or imported to the page sources rendered by the browser. This particular specific of these frameworks enables us to create an implementation of the predefined abstract component model in a way that allows all users of that framework to employ it Model requirements From the motivation of creating such a model as in4.1 arise model requirements, which can be defined as follows: The API should be written in the way, that would provide methods for basic use cases of the particular component. In other words, the majority of the components from different frameworks should be able to implement that particular API. It should provide cross browser compatibility for testing. It should support rapid development and enhance a type safety. 3. Controller is that part of the MVC which handles user input and controls the data flow from business logic to the View layer. 4. Do not meet all the specifics of the component based frameworks. 31

39 4. Component Model It should be integrated with selected framework (Arquillian Drone) from tools evaluation, chapter 3. Those are the general requirements. However, there were other demands on the abstract model. Particularly, we need to define a mechanism to determine what component we are communicating with, since there can be several components of the same type on one tested web page. The created API and its implementation should encourage testers to use object oriented testing patterns (see the following section). 4.2 Object Oriented UI Testing Patterns Regarding to model requirements we are identifying various UI testing patterns. one of them is Page Objects patter. As all patterns, this one is also a result of experience, and this comes particularly from automation of UI tests Page Objects Its main objective is to model Web page areas into objects to reduce the amount of the duplicated code and also to enhance the tests maintainability [37]. The key principles used to achieve this and best practices for working with Page Objects are [37]: the HTML structure of the page is defined only in one place - so that the change in the HTML code will affect tests as little as possible Page Objects expose services to developers, in other words provide methods to interact with page these methods should again return other Page Objects - this encourages test developers to interact rather with the services than with the implementation. As a result they are able to control which tests will fail. Easily said, it means better maintainability Page Objects do not have to represent whole web site, they can be just part of it 32

40 4. Component Model An example of such Page Object can be the online translate service (Google Translate 5 ) provided by Google Inc. The primary service it provides is of course translating from one language to another. But to do so, user often need to choose both from and to which language to translate particular word. Programmatically speaking, implementing the Page Object for such a Web page using the WebDriver can be written as the code snippet 4.3. The connection between this code and the Google Translate page is represented in a more comprehensive way in figure 4.2. Figure 4.2: Screenshot of Google Translate page (20th April 2012) with references to the code lines from public class GoogleTranslate { 2 xpath = " // input submit ] " ) 4 private WebElement t r a n s l a t e B u t t o n ; 5 xpath=" // t e x t a r e a source ] " ) 7 private WebElement inputarea ; 8 5. Google Translate, 33

41 xpath=" // span result_box ] " ) 10 private WebElement r e s u l t A r e a ; public S t r i n g t r a n s l a t e ( S t r i n g word ) { 13 inputarea. sendkeys ( word ) ; 14 t r a n s l a t e B u t t o n. c l i c k ( ) ; (new WebDriverWait ( webdriver, 4) ). u n t i l (new ExpectedCondition <Boolean >() { Component Model 18 public Boolean apply ( WebDriver d ) { 19 return ( r e s u l t A r e a. gettext ( ). trim ( ). l ength ( ) > 0) ; 20 } 21 }) ; return r e s u l t A r e a. gettext ( ). trim ( ) ; 24 } public void selectlanguagetotranslateto ( Language language ) { 27 // implemented in the s i m i l a r way 28 } public void selectlanguagetotranslatefrom ( Language language ) { 31 // implemented in the s i m i l a r way 32 } 33 } Listing 4.3: Google Translate - example of Page Object written in Java programming language. As it is in accordance with the best practices this Page Object can be used in the functional test of the translating service as demonstrated by the code snippet. What was meant by best practices is that only the GoogleTranslate object distinguishes the HTML structure of the real web page. Better said, it holds this information in WebElement objects - e.g. it knows that the translated result area has id set to result_box value. This Page Object can be used in the functional test of the translate service as demonstrates the code snippet Let s suppose that you want to use interaction with the Google 6. It is only truncated example of Arquillian test. 34

42 4. Component Model Translate in other test scenarios, or rather in other test methods, classes or even projects. Then imagine that the Translate button will be removed, and the translation will be triggered automatically, during filling in the input the particular word by releasing the key. The above mentioned does not have to be just artificial change scenario. This can be easily done later for rendering that page on mobile devices, as the automated translation has already been implemented. Furthermore, it is needed to render as few items on mobile devices as possible. 7 Then the only place which will need to be changed will be the Page Object, all dependent test classes will remain untouched. Hereby we reach the goal, enhancing tests maintainability. 1 public class TestGoogleTranslate extends A r q u i l l i a n { 2 4 private GoogleTranslate g o o g l e T r a n s l a t e ; 5 7 WebDriver webdriver ; 8 10 public void testtranslateword ( ) { 11 g o o g l e T r a n s l a t e. selectlanguagetotranslatefrom (new Language ( " sk " ) ) ; 12 g o o g l e T r a n s l a t e. selectlanguagetotranslateto (new Language ( " en " ) ) ; S t r i n g wordtotranslate = " ryba " ; 15 S t r i n g e x p e c t e d T r a n s l a t i o n = " f i s h " ; S t r i n g a c t u a l T r a n s l a t i o n = g o o g l e T r a n s l a t e. t r a n s l a t e ( wordtotranslate, webdriver ) ; The reason is obvious, as mobile devices have smaller screens, mobile application developers need to save space as well as size of requested data. 35

43 4. Component Model 19 a s s e r t E q u a l s ( a c t u a l T r a n s l a t i o n, expectedtranslation, " The word was t r a n s l a t e d i n c o r r e c t l y! " ) ; 20 } } Listing 4.4: Example of the Arquillian functional test of the Google Translate page, written in the Java language. In the abstract model created for this thesis, Page Objects are supported as demonstrated on lines 3 and 4 in figure 4.4. Note the differences between default WebDriver project and created model. Prior to the usage of the particular Page Object, this object needs to be initialised properly. It means that all WebElements of that Page Object (lines 4, 7, 10 in code snippet 4.3) need to be initialised with a proper object so that they would not encounter NullPointerException. 8 As opposed to WebDriver project, this initialisation is done with use of a factory method. We have implemented Page Java annotation(line 3 in code snippet 4.4) which will be recognized in the runtime by Drone extension and initialized with particular Page Object. Further information about integration with this extension is described in section Component Objects Another pattern, or better said good OO (Object Oriented) approach to design reusable code is Component Object. It is very similar to the Page Objects. It also indentifies parts of the Web page and its services, however in a finer grained way. The objective of this is to provide components which are highly reusable. This pattern will be used mainly for creation of the API, its consequences are particular components. It is based on Component-Based Architectural Style. This style provides a higher level of abstraction by decomposing of the design into logical or individual components that expose well-defined interfaces containing methods, events, and properties. Components designed in this style should follow following principles [38]: 8. Java Exception thrown e.g. when invoking method on field with null value. 36

44 4. Component Model Reusable - they should be designed in a way to be easily reused in other parts of the same or different application; Replaceable - components should be easily replaced by other components; Not context specific - the state should not be included into components, it should be passed to them; Extensible - to provide a new behaviour, a component should be easily extended; Encapsulated - basic OO rule that methods should not expose the internal implementation, variables or state; Independent - in order to use components in other environments, there should be minimal number of the component s dependencies. Abstract component model implemented for this thesis are trying to meet this requirements. Components are reusable across all projects, they are defined in the Java, but the implementation can describe any component-based Web framework They can be easily added to your project as Apache Maven. One implementation of the component can be replaced by another. This is achieved by defining at first common interface for that component. Then, with regards to the another OO design principle, program to an interface, not an implementation [39], the component dependency can be replaced by the other component, as the second component also implements the common interface. The interfaces for components do not contain state, however, the implementation does. This is the specific of the component-based frameworks. The framework that the HTML code generated for the particular component is the same for all applications. More information about this specific can be found at the section Another state which needs to be accessible for components, is which browser they are rendered on. However, this information is injected into them in runtime by Arquillian DI (Dependency Injection) mechanism, so it is not wired with components. 37

45 4. Component Model The implemented components are also extensible, because the implementation classes are non final and define public constructors, or to be more precise they do not define private constructors. The new behaviour can be then added by the standard extension Java mechanism. It is then on the developer, whether his components will be extendable or not, but the standard ones, from the abstract model are. Components are encapsulated by encapsulating all the methods, in other words, the Javadoc 9 and the names of the methods are not exposing how their service is done, which means that the particular implementation is hidden. Let s take the Google Translate Web page into consideration one more time. This time the whole page will be divided into smaller parts. Figure 4.3: Google Translate Web page screenshot (20th April 2012) with components identified. Several components can be identified in the Web page from figure4.2. These components can be used in other pages. Among the simple components we can see following: button, select and text area, continuing with more complex like tab panel or virtual keyboard. The figure 4.3 shows a graphical representation of those. 9. Javadoc - way of creating documentation for Java methods, classes and other structures. 38

46 4. Component Model 4.3 Implementing the Component Model All previous sections described our component model in general way. Following sections will describe the implementation in detail Employed Java technologies Above all, we need to define which specifics of Java programming language we used for implementating component model. Java Reflection Reflection is a feature of Java language, used by programs to examine, or modify the runtime behaviour of applications. It is an advanced feature which needs to be employed with following concerns kept in developer s mind [40]: Performance overhead, because Java virtual machine 10 (JVM) optimizations can not be done for dynamically resolved reflection types, parts of the code which use reflection have slower performance, and therefore in performance demanding applications, using of reflection should be considered carefully; Security restrictions, when the application is running under security manager 11, some of the required reflection permissions do not have to be permitted; Exposure of internals, because with use of reflection operations, it is for example possible to access private 12 fields and methods, it can have unexpected side-effects, and can destroy portability of the application. Reflection behaviour can be changed with upgrades of Java platform, which can cause that application cease to function. 10. The environment where all Java applications run. 11. A mechanism in Java to determine security policy of the application, that is actions which are permitted to perform in an application. 12. Private is key word in Java to determine fields and methods which can be directly accessed only from the class, where they are defined. 39

47 4. Component Model Listing 4.4 shows an example of Java class and its fields declared on lines 4 and 7, its method on line 10. That class does not have defined constructor explicitly, therefore a default one is defined for it. Wile using reflection it is possible to for example access and manipulate this class, its fields and constructors during runtime. Listing 4.5 shows an example of such manipulation with this class. On line 5, all declared fields are retrieved. On line 7 we are iterating over this array of all declared fields, retrieving the name of the field, its annotation Page if exists, information whether the field is accessible, and its generic type. On line 20, there is a demonstration of a way of creating new instances of classes. 1 public class S h o w c a s e R e f l e c t i o n C a p a b i l i t i e s { 2 3 public static void main ( S t r i n g [ ] args ) throws I n s t a n t i a t i o n E x c e p t i o n, I l l e g a l A c c e s s E x c e p t i o n { 4 5 F i e l d [ ] d e c l a r e d F i e l d s = TestGoogleTranslate. class. g e t D e c l a r e d F i e l d s ( ) ; 6 7 for ( F i e l d i : d e c l a r e d F i e l d s ) { 8 S t r i n g name = i. getname ( ) ; 9 Page annotation = i. getannotation ( Page. class ) ; 10 boolean i s A c c e s s i b l e = i. i s A c c e s s i b l e ( ) ; 11 Type type = i. gettype ( ) ; System. out. p r i n t l n (name) ; 14 System. out. p r i n t l n ( annotation ) ; 15 System. out. p r i n t l n ( i s A c c e s s i b l e ) ; 16 System. out. p r i n t l n ( type ) ; 17 System. out. p r i n t l n ( ) ; 18 } TestGoogleTranslate i n s t a n c e = TestGoogleTranslate. class. newinstance ( ) ; 21 System. out. p r i n t l n ( i n s t a n c e ) ; 22 } 23 } Listing 4.5: Java Reflection example. List of Java Reflection features is not completed with these few ones described, but these are almost all, which were used in the implemen- 40

48 4. Component Model tation. Moreover one another Java reflection feature is utilized in the implementation model, which is quite fundamental, and that is Java Dynamic Proxies. Java Dynamic Proxies Firstly, we need to define Proxy pattern. Formally, it can be defined as a pattern that provides a surrogate for another object to control access to it. A class diagram for this pattern is shown on Figure 4.4. Both Proxy and RealSubject classes implement a common interface Subject. Hence when a RealSubject instance is needed, the Proxy instance can be used instead. Usually, Proxy instance contains reference to the RealSubject, and dispatches the method invocations to it [39]. Figure 4.4: UML Class diagram for Proxy Pattern. There are several reasons for creating a surrogate object, and then the names of the proxies are inferred from this reasons; for example it is created to control access to a network resources (Firewall Proxy), it can be created to provide temporary storage for results of expensive operations (Caching Proxy), or to act as local representative for an object that does run in the same address space (Remote Proxy), in the case of Java language, in the same JVM. Java Dynamic Proxies is a mechanism for creating a Proxy object at runtime, that implements an interface, or multiple interfaces, and forwards methods invocations to a specified class. They are created as stated in the previous section with use of Java Reflection API. The 41

49 4. Component Model class diagram for Java Dynamic Proxy (Figure 4.5) differs a little from the general Proxy class diagram, because it is supplemented with InvocationHandler class. Its purpose is to respond to any method calls on the Proxy; it is the way of declaring what Proxy has to do before invoking method on the real object [39]. An example of the Java Dynamic Proxies use case is creating dynamic mock objects for unit testing. Figure 4.5: UML Class diagram for Java Dynamic Proxy Pattern. Java Generics Java Generics is a feature added to Java language in version 1.3. Its main purpose is to enhance type-safety. Consider following Listing 4.6, which demonstrates the problems, when not using Java Generics. The class Drawer enables to add any object to it, because its field is of the Object type, which is the super type of all Java objects. The main method of the class ShowcaseGenericProblems is compiled without problems, however, when running, ClassCastException Java exception is thrown because of line 20, where we are trying to cast an object of type String to an object of type Object. This is just an artificial example, but similar problem can easily occur in real-world examples. The main problem is that it is not caught at compile time, but it is exposed during runtime. Listing 4.7 solves this problem by using of Generics. GenericDrawer has generic type T, which can be supplemented by 42

50 4. Component Model any type, and the return value of method getitem is also of the generic type T. In the main method of the class GenericsSolution, we are performing the same scenario as in previous example, only the instantiation of the class Drawer uses generics now. Note that is not possible to even compile GenericsSolution class, we get the error message "Cannot cast from String to Integer". The result is expected and desired as we want to catch this type of errors during compile time. 1 public c l a s s GenericDrawer<T> { 2 3 private T item ; 4 5 public void additem (T item ) { 6 this. item = item ; 7 } 8 9 public T getitem ( ) { 10 return this. item ; 11 } 12 } public class G e n e r i c s S o l u t i o n { public static void main ( S t r i n g [ ] args ) { GenericDrawer<String > drawer = new GenericDrawer<String >() ; 19 drawer. additem ( " pen " ) ; I n t e g e r pen = ( I n t e g e r ) drawer. getitem ( ) ; 22 } 23 } Listing 4.6: Example demonstrating type-safety problem when not using Java Generics. 1 public class Drawer { 2 private Object item ; 3 4 public void additem ( Object item ) { 5 this. item = item ; 6 } 7 8 public Object getitem ( ) { 43

51 9 return this. item ; 10 } 11 } public c l a s s ShowcaseGenericProblems { public static void main ( S t r i n g [ ] args ) { Drawer drawer = new Drawer ( ) ; 18 drawer. additem ( " pen " ) ; I n t e g e r pen = ( I n t e g e r ) drawer. getitem ( ) ; 21 } 22 } 4. Component Model Listing 4.7: Example of solving type-safety problem from Listing 4.6 with using of Java Generics. Service Provider Interface Service Provider Interface (SPI) is a mechanism to create modular, plug-in architectures 13 which are easy to maintain. For example an upgrade of one part should not affect whole application. In Java environment, SPI is a set of public interfaces and abstract classes which defines a service contract. Service provider than has to implement these interfaces, and hence also this contract to fetch its functionality into the application. The exact procedure looks as [41]: 1. The desired functionality which we want to add is packed in a JAR 14 file and is on the application classpath 15 ; 2. You have to identify the provided service by placing a file into the directory where the sources of your application are, and under it to the directory /META-INF/services, which contains a fully qualified service name An architecture which allows to add functionality by adding to it small modular applications, so called plug-ins. 14. The type of archive in which a Java applications are distributed. 15. It is a parameter to tell JVM where classes are located. 16. A name which is complete in a sense that it contains all names in the sequence above and the name itself, an example is java.lang.string [42]. 44

52 4.3.2 Integration with existing Frameworks 4. Component Model It is always a good practice to not to reinvent a wheel by implementing the whole functionality from the beginning. When creating a new project, utilize already implemented functionality from other frameworks. What frameworks, and how the created component model utilizes them, is described in this section. WebDriver WebDriver automation tool is already mentioned in the section 3.2. In the created abstract model, it will be the main automation tool, in other words, it will be used to make interactions with the browser. Currently, Arquillian Graphene is used to obtain an instance of WebDriver, which is subsequently injected into the test object. To instruct WebDriver what web page element we want to communicate with, it uses already seen mechanism of WebElement. For example line 4 at Listing 4.3 declares such a WebElement by specifying the XPath of the particular element which is in that example string //input[@type= submit ]. XPath is a way of navigation in an XML document, and the structure of all web pages is also connected with their Document Object Model (DOM) which is a tree model of all web page elements, constructed in an XML syntax. This particular string locates a submit button. There are also other ways of locating web elements, such as CSS selectors. WebDriver root mechanism What is particularly utilized, is the way of locating nested elements of the particular web element. Listing 4.8 shows demonstration of the nested elements. A HTML code of two components can be seen, particularly RichFaces calendars. Note that the HTML structure of that two components is the same, only values of attribute id are unique. The value of id is, however, generated randomly, and differentiates from one rendering to another. That is the reason why can not rely only on locating according to id value, but there has to be employed locating according to other characteristics, for example CSS class, or the position in the DOM tree. Based on the research, I discovered that the only thing which de- 45

53 4. Component Model termines the particular component unambiguously is its root element (lines 1 and 12). We can reference from this root other component s parts. It is possible because of WebDriver root mechanism which is shown in Figure 4.6. It shows two approaches of locating WebElement, firstly when locating from WebDriver object elements with class nice, two elements are found (blue marked). When locating the first Root 2 element, and from it elements which have class nice, only one element is found (red marked). Figure 4.6: WebDriver way of locating elements. When taking into consideration the listings 4.8 again, referencing an img element with class rf-cal-btn from its root element <span id="j_idt6:calendar1"> (line 1), the image (line 5) from the first calendar will be selected, not the second one (line 16), even though it has the same class. This is used in component model to access different parts of the components. For example the above mentioned image is a trigger which has to be clicked on in order to show a calendar in a pop-up panel. Hence each component needs to have set root, before any action can be taken with it. Each component s interface therefore needs to extend defined Component interface, which contains method setroot, and therefore forces a user to implement that method. 46

54 4. Component Model 1 <span id=" j _ i d t 6 : c a l e n d a r 1 "> 2 <span id=" j_idt6:j_idt9popup " s t y l e=" white s p a c e : nowrap ; "> 3 <input c l a s s=" r f cal inp " id=" j_idt6:j_idt9inputdate " name=" j_idt6:j_idt9inputdate " 4 readonly=" readonly " s t y l e=" v e r t i c a l a l i g n : middle ; " type=" t e x t " /> 5 <img a l t=" " c l a s s=" r f cal btn " id=" j_idt6:j_idt9popupbutton " 6 s r c=" path / toimage / c a l e n d a r I c o n. png " 7 s t y l e=" v e r t i c a l a l i g n : middle " /> <span id=" j _ i d t 6 : c a l e n d a r 2 "> 13 <span id=" j_idt6:j_idt10popup " s t y l e=" white s p a c e : nowrap ; "> 14 <input c l a s s=" r f cal inp " id=" j_idt6:j_idt10inputdate " name=" j_idt6:j_idt10inputdate " 15 readonly=" readonly " s t y l e=" v e r t i c a l a l i g n : middle ; " type=" t e x t " /> 16 <img a l t=" " c l a s s=" r f cal btn " id=" j_idt6:j_idt10popupbutton " 17 s r c=" path / toimage / c a l e n d a r I c o n. png " 18 s t y l e=" v e r t i c a l a l i g n : middle " /> Listing 4.8: Web page fragment demonstrating two components - calendars - at one page. Arquillian Drone After the creating a prototype for the first selected component, calendar (its implementation in Listing 4.9), the usage of this component in the test looked like Listing The Calendar component from listing has two fields, one annotated with Root annotation, which represented the field for later setting of the actual root, and the second annotated with annotation FindBy with 47

55 4. Component Model value according to which the element was inferred from component s root. To use the component in the test, the tester had to initialise the component first with created Factory class, and secondly set the actual root, when the page was loaded, because only then the actual root can be located. Initialisation of components The problem was to initialize component properly. The components fields annotated with annotation FindBy needed to recognize the actual root by which they were inferred. This made an obligation to at first locate the actual root and to inject WebDriver and the root to the Factory class, which can properly initialise particular annotated fields with use of Java Reflection. We wanted to avoid this obligation. It was resolved with use of Java Dynamic Proxies (see section 4.3.1). So when initialising the component, instead of injecting the real instances of WebElements, Dynamic Proxies objects are inserted, which invocation handlers forward all method invocations to the real WebDriver object. More comprehensive will be probably the study of the Factory class, and its methods. Appendix B shows the fragments of the Factory class, the most important method, initializecomponent. This method is generic (see section 4.3.1), and can initialise any class which extends AbstractComponent class, it is a constraint to avoid initialising classes which are not components. With the use of method instantiatecomponent, whose internal implementation is using Java Reflection (see section 4.3.1), the given component is instantiated, in other words a new object is created from the given class. In next the steps, all declared fields and subsequently all annotations of given field are retrieved with the use of Java Reflection, and iterated over to initialise root element and other fields with Java Dynamic Proxy objects. The initialisation of root element begins on line 17, we are creating new Proxy, and assigning to it invocation handler class. This method invoke will be called every time when any method will be called on the root element. In that method we retrieve the actual root, which should have already been set to the rootreference by the time that the method is invoked. Similar proxy objects are injected into fields annotated with FindBy 48

56 4. Component Model annotation 17, with the difference that it finds the actual WebElement from the root. 1 public class CalendarImpl { 2 4 private WebElement root ; 5 c s s = " img : nth of type ( 1 ) " ) 7 private WebElement showcalendarbutton ; 8 9 public void showcalendar ( ) { 10 showcalendarbutton. c l i c k ( ) ; 11 } 12 } Listing 4.9: First Calendar component prototype of the implementation. 1 public c l a s s TestPageWithCalendar { 2 3 private CalendarImpl c a lendar ; 4 6 public void i n i t C a l e n d a r ( ) { 7 c a l e n d a r = Factory. i n i t i a l i z e C o m p o n e n t ( CalendarImpl. class ) ; 8 } 9 11 public void loadtestpage ( ) { webdriver 14. get ( " http : / / l o c a l h o s t :8080/ mytestapp/ calendar. j s f " ) ; calendarroot = webdriver 17. findelement (By. xpath ( " // td = e c o l 1 ] " ) ) ; 18 c a l e n d a r. setroot ( calendarroot ) ; 19 } 17. Note that it is standard annotation of WebDriver, so it will be good recognized by community. 49

57 4. Component Model public void t e s t C a l e n d a r S e r v i c e ( ) { 23 c a l e n d a r. showcalendar ( ) ; 24 } } Listing 4.10: Usage of first calendar implementation. The next problem was that demonstrated using of calendar component is clumsy, because the initialisation and the setting of the root will be repeated for every component, it is worth to automate it, to enhance created framework usability. Therefore we decided to utilize again FindBy annotation, so that the calendar component will be annotated by FindBy annotation, which will provide information about the position of the root element on the tested page. We needed to discover a mechanism which will perform this automatic discovery of FindBy annotations. Drone SPI Arquillian provides a way to manage this by providing SPI (see section 4.3.1) for enriching the test, which is a way to inject various dependencies into the test object during runtime. I just needed to provide an implementation for that SPI. Appendix C.1 shows some important fragments of this implementation. With the use of reflection it initialises at first fields annotated with FindBy annotation, it can be either components, then also the root is set to that component, or it can be other elements which we need to interact with. Secondly, the fields with Page annotation are initialised, it is support for Page Objects pattern (see section 4.2.1), so you can use various pages in the test. These pages can contain other components, and the page object and its parts are properly initialised by Drone extension. Arquillian Drone was also used in functional tests for the created component model. 50

58 4.4 Component Case Studies 4. Component Model Designing a good API is complicated, because it is not possible to meet all user s requirements. To determine whether an API is good, we firstly have to realise what is the objective of creating an API. I would like to provide the users of our API with a way to easily assemble their application with use of our API, that this operation of assembling will be easy and will avoid debugging and reading source code, and furthermore will be understandable for majority of developers. An API is also created when we want to achieve distributed development of our application [43]. Good API design First of all, when creating an object oriented (OO) API, all the OO principles, like encapsulating what varies, favouring composition over inheritance, program to interfaces not implementations, do not call us we call you [39], need to be followed to be successful. However, it is not sufficient for creating an API, it can be sufficient for creating an application with use of that API. Jaroslav Tulach, a founder and initial architect of NetBeans IDE, and currently the development lead advises to keep in mind following principles when creating an API [43]: You have to develop a trusting relationship between you and other programmers, you have to convince them that you are able to produce and maintain stable API. In practice it can means to maintain backward compatible API, which is an API which when evolves, the older contract of the API remains the same, while new functionality is added. To be more specific, when implementing an interface in Java, it can not happen that new methods with new releases will be added to that interface, as it would break the whole code, because the implementations would not contain the new methods. It is important to be use case oriented. It is not possible to know all API users, and therefore their needs. Therefore the solution is to be use case oriented, what means to work with vision of users actions. The starting point of any design should be answering the questions: Why? What? How? That is why we started with possible use cases of future components. Their can be clearly viewed from Unified Modeling Language 2 diagrams 51

59 4. Component Model (UML 2), such as Use Case diagram 18, and Sequence diagram 19. In following sections we describe such diagrams for three created components, Autocomplete (section 4.4.1), Table (section 4.4.2), and Calendar (section 4.4.3) Autocomplete component Figure 4.7: RichFaces Autocomplete component. Autocomplete component (Figure 4.7) represents an input into which, when a user starts to write, a box with suggestions is provided. From this suggestions the user can choose either by mouse or by keyboard. Upon choosing one of the suggestions, the input will be filled with it. The user can also continue writing. Figure 4.8 shows Use Case diagram, which captures possible use cases of the Autocomplete component. Individual use cases are self descriptive, after all that is their intention, just to note that the label «include» means, that the included use case needs to be performed at least once in order to perform the use case which is performing inclusion. In the appendix D we can see Sequence diagram for Autocomplete component. It shows a possible test scenario, or in other words, some of the use cases ordered in time. 1. The tester at first retrieves expected data from a database, and then fills in the input with prefix of word, which also returns all available suggestions. 18. Use Case diagram, Sequence diagram, library/3101.html. 52

60 4. Component Model Figure 4.8: Autocomplete component Use Case diagram. 2. Then he can fill in the input with prefix of word, which should not have any suggestions, and assert the expected state. 3. The last Autocomplete behavior he is testing is autocompletion with some suggestion. This performs two times, and then once filling in the input value with no suggestions. 4. After fetching all selected suggestions he will verify that only values, which were selected from suggestions were retrieved. This is a simple example of the use of a model for component Autocomplete. More real-world example is provided in section 4.5 An API for this component was created with considering these two diagrams. Its key behaviors are: Autocomplete component has generic type, this type determines what kind of suggestions it can provide, for example plain text, or tables with pictures; user of this API will be able to get all available suggestions, or just the specific suggestions; 53

61 autocomplete with specified suggestion; clear the input; 4. Component Model set separator, which separates selected suggestions, or to use the default one; get all values from the input, which were filled in with autocompletition from a suggestion list; suggestion is encapsulated in the class Suggestion For more please see the generated Javadoc documentation Table component Figure 4.9: RichFaces Table component. Data table component (Figure 4.9) represents an HTML table. HTML table supports creating of headers and footers, connecting cells into one, and rendering not only a textual information into the cells. Cells can contain for example pictures, inputs or other HTML elements. 54

62 4. Component Model Figure 4.10 shows possible use cases of the Table component. The component should provide a way to get any part of the table, like particular cell, column or row and also their content (e.g. Get Any Part of Table, Get Table Header/Footer, Get Content of Table Part). It should also be possible also to find parts of the table according to some filter function (Find Parts of Table, Determine Which Parts of Table). The last example of functionality is a mechanism for iterating over multiple table pages. Appendix E.1 shows possible test scenario of table component. With regards to Figure 4.9, typing values into the input nested in the header causes triggering of filter function, which subsequently renders only rows which conform the filtering function. The test scenario is based on this functionality, therefore the first step is to create a table with particular columns, get the input element from the first header cell, type a string into that input, and iterating over rendered filtered rows, to assert that they contain only values which agree with the filled in value. Figure 4.10: Use Case diagram of the Table component. The Table component is indeed the most complex component, as it has to deal with the fact that the cells may contain any possible element: text values, numbers, pictures, or other elements for which the 55

63 4. Component Model API was created, like for example Calendar component or mentioned Autocomplete component. The hierarchy of Table component (Class diagram in Figure 4.11) consists of base class TableComponent, their parts: Cell, Column, and Row s special cases: Header and Footer. TableComponent1 and TableComponent6 extends the TableComponent, as it is not possible to define base class with variable number of generic parameters, and therefore each number of columns has to have its own specific class. As it can be seen in the example, 6 columns table is represented by TableComponent6 and so on. Cell is a special case of generic ComponentsContainer which can contain other NestedElements. RowFunction, ColumnFunction and CellFunction defines one method, accept (inspired by the Command pattern 20 ). This interfaces should be implemented by the end user of the component, to determine filtering function for cells, rows and columns, which instances are then passed to e.g. Table function findcells. Figure 4.11: Class diagram of the Table component. 20. Command pattern, general information at Command_pattern. 56

64 4. Component Model Calendar component Calendar component (Figure 4.1) serves for selecting particular date, and then for showing the selected date. The Use Case diagram from Figure 4.12 may at first sight appear that lot of possible calendar s behaviour is missing, however, the API should be abstract enough to include all type of implementations. This particular diagram is for the most abstract calendar, as with all calendars it should be possible to select the date and then retrieve the selected date. Figure 4.12: Calendar component Use Case diagram. To implement more specific calendars, a user can extend this abstract calendar and provide API for his desired calendar implementation. I did it, and implemented the API for calendar which when is invoked is rendered in a popup, and the selected date is shown in the input. This type of calendar is for example implemented in RichFaces and JQuery UI (see the section 4.1.1). Its Use Case (Figure 4.13) diagram is richer in number of behaviors. The Sequence diagram for Calendar Popup component can be found in appendix F. It is again demonstrating an example of a typical interaction with a particular component, in this example simultaneously with two calendars. So for example a tester can: 1. Set the next day date on the first calendar, that would represent an start time of some activity. 2. set the date, for example a month and two days after current date to the second calendar, that would represent an end of the activity. 57

65 4. Component Model Figure 4.13: Popup Calendar component Use Case diagram. 3. Get the selected dates from both calendars, and verifies that expected dates were selected. 4. Then he can go to the current date on the first calendar and to the date of previous day on the second one. 5. Finally he verifies that an error message was rendered, because the beginning date can be not after the end date of the activity. The Calendar Popup component encapsulates these possible interactions between the user and the component itself: user of the component will be able to show and hide the calendar, that is, render it in the popup mode and then hide it to show only the input with selected date; it will be possible to clean the input; get selected time unit; the time unit is type-safe encapsulation for day, week, month and year; select the previous or next time unit; 58