{"id":122,"date":"2011-08-13T13:16:12","date_gmt":"2011-08-13T12:16:12","guid":{"rendered":"http:\/\/blogs.igalia.com\/javimoran\/?p=122"},"modified":"2012-08-14T16:33:24","modified_gmt":"2012-08-14T14:33:24","slug":"bringing-functional-tests-to-navalplan-libreplan","status":"publish","type":"post","link":"https:\/\/blogs.igalia.com\/jmoran\/2011\/08\/13\/bringing-functional-tests-to-navalplan-libreplan\/","title":{"rendered":"Bringing Functional tests to NavalPlan (LibrePlan)"},"content":{"rendered":"<p><strong>Chasing Quality<\/strong><\/p>\n<p>One of the maxims we try to follow in <a href=\"http:\/\/www.navalplan.org\">NavalPlan (LibrePlan)<\/a> is to create a project with good quality.<\/p>\n<p>Quality in software refers to two different notions:<\/p>\n<ul>\n<li><em>Functional quality<\/em>. It is the degree in which a software satisfies the specifications. The better the software complies with them, the higher the quality a program is.<\/li>\n<li> <em>Structural quality<\/em>. It is related to all the non-functional requirements which can be stated over a program. For instance, how good is the development cycle, how maintainable the source code is, what performance is achieved, etc.<\/li>\n<\/ul>\n<p>Said that and taking into account this classification, I would like to introduce automated web tests and relate them to this taxonomy.<\/p>\n<p>In the first place, I will define what they are for those of you not familiarized with them. In short, we can say that automated web tests are black box tests in which the interface of a web application is tested in an automatic way. In other words, they are a type of tests in which a program performs the role of a real user and interacts with web pages with the aid of a browser to assure that the behavior of a web application is the one expected.<\/p>\n<p>In second place, as I told you, I would like to link them with quality. In general, we can say that they provide structural quality because, on the average, a web application with functional tests has a higher quality than one application without them. They help to detect failures and regressions and, therefore, in the end, the likelihood of having bugs is smaller.<\/p>\n<p><strong>Sahi Web Tests<\/strong><\/p>\n<p>In the NavalPlan team we have been looking for the best alternative to do automated web tests. Apart from the general cited reason of having higher quality, we try to address the jointly effect of having a large-featured application and a short-numbered testing team. When these two factors are combined the likelihood of regressions is big and the cost of a comprehensive manual test of the application high. Therefore, for sure, with a good set of web tests we would improve both in robustness and productivity allowing us to plan less testing time.<\/p>\n<p>After looking for several alternatives, the technology that we chose is <a href=\"http:\/\/sahi.co.in\/w\/\">Sahi<\/a> and the reasons which supported our decision are the next ones:<\/p>\n<ol>\n<li><em>In NavalPlan we use the web interface framework <a href=\"http:\/\/www.zkoss.org\/\">ZK<\/a><\/em>. This is a framework which generates dynamically the <em>id<\/em> attribute of the HTML entities which make up the web pages. This makes difficult to develop automated tests because the <em>id<\/em> is one of the easiest ways to locate HTML entities in the DOM and, some of the most common testing frameworks, like <a href=\"http:\/\/seleniumhq.org\/\">Selenium<\/a>, relies basically on them. However, as they are dynamic in ZK, i.e., each time a page is rendered they are different, it is impossible to make the tests being repeatable with a technology based on the <em>ids<\/em>. Luckily, Sahi allows to overcome this situation because it has a powerful accessor API which helps to locate HTML elements using concepts like indexes, human DOM relationships as can be near or parent, CSS classes, etc.<\/li>\n<p><\/p>\n<li><em>Sahi is browser independent<\/em>. This means that the automated tests can be executed in several browsers. This is great, because a <a href=\"http:\/\/en.wikipedia.org\/wiki\/Rich_Internet_application\">RIA<\/a> application like NavalPlan uses the latest HTML technologies and some of them might be not fully supported in a particular browser. We can run the tests in all of them and this is a big advantage for us.<\/li>\n<p><\/p>\n<li><em>Tests are programmed in JavaScript what in my opinion is a great idea<\/em>. To start with, because JS is the language used by browsers since the very beginning and is a standard with a good API to interact with the DOM. Another good feature is that, because of being the tests written in a programming language, we have the programming tools like functions, data types, control structures&#8230; which gives you the highest flexibility to build tests as complex as you need. Some other testing technologies relies on configuration files, like XML files, and this limits a lot the possibility to get off the path of what the web test framework developers initially thought. <\/li>\n<\/ol>\n<p>Now I will focus on the things I would like to be different in Sahi. Among them, I would highlight that there is a proprietary product (<a href=\"http:\/\/sahi.co.in\/pro\/Sahi_Pro_V_1_0.htm\">Sahi Pro<\/a>) built on top of the Sahi Open Source. Sahi Pro provides the more advanced features and I really miss that some of them were in the open source product. For example, a better report system. For me it would be nice that they had an open source license for the Sahi Pro product to be used with free software products like NavalPlan.It is a way to promote both quality in open source and open source itself without damaging the comercial interests of a company supporting a free software product.<\/p>\n<p><strong>Where are we ?<\/strong><\/p>\n<p>We started developing Sahi tests last month and, at present, we have tests for some of the simpler use cases, which are CRUD use cases related to administrative operations. If you feel like having a look to how they work, I encourage you to deploy NavalPlan, to download the git repository and to read the <a href=\"http:\/\/navalplan.git.sourceforge.net\/git\/gitweb.cgi?p=navalplan\/navalplan;a=blob;f=scripts\/functional-tests\/README;h=b36d75004df2b76b48ca01f852ab192ec0d717f5;hb=HEAD\">README<\/a> file  in the <em>script\/functional-tests<\/em> folder where the instructions to run them are described.<\/p>\n<p>Additionally, they say that tests are successful when they detect errors and, in this sense, we proudly \ud83d\ude09 can say that right now we have reported some new bugs on the <a href=\"http:\/\/bugs.navalplan.org\/\">bugzilla<\/a> thanks the functional Sahi tests developed so far.<\/p>\n<p><strong>Where are we going ?<\/strong><\/p>\n<p>Our roadmap concerning web tests will consist of increasing the coverage and facing up more complex interface operations in the near feature. After it,<br \/>\n a last final desired scenario will consist of having a platform in which:<\/p>\n<ol>\n<li>We develop a <a href=\"http:\/\/en.wikipedia.org\/wiki\/Apache_Maven\">Maven<\/a> plug-in or write a configuration to be able to pass the tests integrated in the building process as part of the Maven test phase.<\/li>\n<li>In NavalPlan we use <a href=\"http:\/\/en.wikipedia.org\/wiki\/Continuous_integration\">CI<\/a> and the continuous integration server we have is <a href=\"http:\/\/en.wikipedia.org\/wiki\/Hudson_%28software%29\">Hudson<\/a>. It would be great to integrate the Sahi tests execution in Hudson build cylce and to have the test results published in the Hudson interface to find them easily.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"<p>Chasing Quality One of the maxims we try to follow in NavalPlan (LibrePlan) is to create a project with good quality. Quality in software refers to two different notions: Functional quality. It is the degree in which a software satisfies the specifications. The better the software complies with them, the higher the quality a program &hellip; <a href=\"https:\/\/blogs.igalia.com\/jmoran\/2011\/08\/13\/bringing-functional-tests-to-navalplan-libreplan\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Bringing Functional tests to NavalPlan (LibrePlan)&#8221;<\/span><\/a><\/p>\n","protected":false},"author":21,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,4,5],"tags":[],"class_list":["post-122","post","type-post","status-publish","format-standard","hentry","category-libreplan","category-navalplan","category-planet"],"_links":{"self":[{"href":"https:\/\/blogs.igalia.com\/jmoran\/wp-json\/wp\/v2\/posts\/122","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.igalia.com\/jmoran\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.igalia.com\/jmoran\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.igalia.com\/jmoran\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.igalia.com\/jmoran\/wp-json\/wp\/v2\/comments?post=122"}],"version-history":[{"count":1,"href":"https:\/\/blogs.igalia.com\/jmoran\/wp-json\/wp\/v2\/posts\/122\/revisions"}],"predecessor-version":[{"id":229,"href":"https:\/\/blogs.igalia.com\/jmoran\/wp-json\/wp\/v2\/posts\/122\/revisions\/229"}],"wp:attachment":[{"href":"https:\/\/blogs.igalia.com\/jmoran\/wp-json\/wp\/v2\/media?parent=122"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.igalia.com\/jmoran\/wp-json\/wp\/v2\/categories?post=122"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.igalia.com\/jmoran\/wp-json\/wp\/v2\/tags?post=122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}