Writing Selenium Tests for Checking Bookmark Feature and Search functionality in Open Event Webapp

We integrated Selenium Testing in the Open Event Webapp and are in full swing in writing tests to check the major features of the webapp. Tests help us to fix the issues/bugs which have been solved earlier but keep on resurging when some new changes are incorporated in the repo. I describe the major features that we are testing in this. Bookmark Feature The first major feature that we want to test is the bookmark feature. It allows the users to mark a session they are interested in and view them all at once with a single click on the starred button. We want to ensure that the feature is working on all the pages. Let us discuss the design of the test. First, we start with tracks page. We select few sessions (2 here) for test and note down their session_ids. Finding an element by its id is simple in Selenium can be done easily. After we find the session element, we then find the mark button inside it (with the help of its class name) and click on it to mark the session. After that, we click on the starred button to display only the marked sessions and proceed to count the number of visible elements on the page. If the number of visible session elements comes out to be 2 (the ones that we marked), it means that the feature is working. If the number deviates, it indicates that something is wrong and the test fails. Here is a part of the code implementing the above logic. The whole code can be seen here // Returns the number of visible session elements on the tracks page TrackPage.getNoOfVisibleSessionElems = function() { return this.findAll(By.className('room-filter')).then(this.getElemsDisplayStatus).then(function(displayArr) { return displayArr.reduce(function(counter, value) { return value == 1 ? counter + 1 : counter; }, 0); }); }; // Bookmark the sessions, scrolls down the page and then count the number of visible session elements TrackPage.checkIsolatedBookmark = function() { // Sample sessions having ids of 3014 and 3015 being checked for the bookmark feature var sessionIdsArr = ['3014', '3015']; var self = this; return self.toggleSessionBookmark(sessionIdsArr).then(self.toggleStarredButton.bind(self)).then(function() { return self.driver.executeScript('window.scrollTo(0, 400)').then(self.getNoOfVisibleSessionElems.bind(self)); }); }; Here is the excerpt of code which matches the actual number of visible session elements to the expected number. You can view the whole test script here //Test for checking the bookmark feature on the tracks page it('Checking the bookmark toggle', function(done) { trackPage.checkIsolatedBookmark().then(function(num) { assert.equal(num, 2); done(); }).catch(function(err) { done(err); }); }); Now, we want to test this feature on the other pages: schedule and rooms page. We can simply follow the same approach as done on the tracks page but it is time expensive. Checking the visibility of all the sessions elements present on the page takes quite some time due to a large number of sessions. We need to think of a different approach.We had already marked two elements on the tracks page. We then go to the schedule page and click on the starred mode. We calculate the current height of the page. We…

Continue ReadingWriting Selenium Tests for Checking Bookmark Feature and Search functionality in Open Event Webapp

Building a showcase site to display sample events and auto deploying them on each PR merge in Open Event Webapp

Open Event Webapp generates static websites of the event fed to it in the form of JSON data. Earlier, we used to automatically deploy the FOSSASIA Summit event website on the Github pages of the repository on every merge of a pull request.  The presence of it helped in showcasing and testing purposes. But a single event was not enough. Events are diverse, taking place in a large number of rooms, h a variety of sessions and extending over several days. So, having multiple events on the showcase site and continuously showcasing and testing them was a really great idea. Here is the feature request for it. I will be explaining the major portions of it. The whole code can be found here First of all, we need to build the main index page which we will showcase our sample events. It will contain the small images of the event and on clicking them, the selected event will be opened. For displaying features and capability of the generator,  we have two separate sections of events: one having the single session page and the other having the expandable sessions page. There will be links to the other components of the Open Event Ecosystem like Android App generator,  Web App generator, Organizer App, and Eventyay. The contents of that page are kept in the overviewSite folder. It contains the event background images of the events and the main index file. The basic structure of the file is shown below. The whole file can be viewed here <div class="container-fluid bg-3 text-center"> <div class="row margin"> <div class="col-md-6 col-sm-12 col-xs-12"> <div class="row"> <h2 class="margin"> Apps with expandable sessions page </h2> <div class="col-md-6 col-sm-6 col-xs-12 margin"> <p><strong>Open Tech Summit 2017</strong></p> <a href='./OpenTechSummit/index.html' target='_blank'> <img src="./otssmall.jpg" class="" alt="Image"> </a> </div> </div> </div> <div class="col-md-6 col-sm-12 col-xs-12"> <div class="row"> <h2 class="margin"> Apps with single sessions page </h2> <div class="col-md-6 col-sm-6 col-xs-12 margin"> <p><strong>Mozilla All Hands 2017</strong></p> <a href='./MozillaAllHands2017/index.html' target='_blank'> <img src="./mozilla_banner.jpg" class="" alt="Image"> </a> </div> </div> </div> </div> </div> But, this is just the front end of the page. We haven’t generated the sample events yet and neither have we made any changes to make them auto deploy on each PR merge. The test script of the app which contains unit, acceptance and selenium tests runs on each PR made against the repo when Travis CI build is triggered. So, it makes sense to write code for generating the event there itself. When the test script has finished executing, all of the events would have been generated and present inside a single folder named a@a.com (We needed something short and easy to remember and the name doesn’t really matter). We then copy the contents of the overviewSite folder into the above folder. It already contains the folder of different sample events. Here is the related code. The full test script file can be found here describe('generate', function() { describe('.create different event sites and copy assets of overview site', function() { // Sample events are generated inside the a@a.com folder it('should generate the Mozilla All Hands 2017', function(done) { var data = {}; //…

Continue ReadingBuilding a showcase site to display sample events and auto deploying them on each PR merge in Open Event Webapp

Testing child process using Mocha in Yaydoc

Mocha is a javascript testing framework. It can be used in both nodeJS and browser as well, also it is one of the most popular testing framework available out there. Mocha is widely used for the Behavior Driven Development (BDD). In yaydoc, we are using mocha to test our web UI. One of the main task in yaydoc is documentation generation. We build a bash script to do our documentation generation. We run the bash script using node’s child_process module, but then in order to run the test you have to execute the child process before test execution. This can be achieved by mochas’s before hook. Install mocha in to your system npm install -g mocha Here is the test case which i wrote in yaydoc test file. const assert = require('assert') const spawn = require('child_process').spawn const uuidV4 = require("uuid/v4") describe('WebUi Generator', () => { let uniqueId = uuidV4() let email = 'fossasia@gmail.com' let args = [ "-g", "https://github.com/fossasia/yaydoc.git", "-t", "alabaster", "-m", email, "-u", uniqueId, "-w", "true" ] let exitCode before((done) => { let process = spawn('./generate.sh', args) process.on('exit', (code) => { exitCode = code done() }) }) it('exit code should be zero', () => { assert.equal(exitCode, 0) }) }) Describe() function is used to describe our test case. In our scenario we’re testing the generate script so we write as webui generator. As I mentioned above we have to run our child_process in before hook. It() function is the place where we write our test case. If the test case fails, an error will be thrown. We use the assert module from mocha to do the assertion. You can see our assertion in first it()  block for checking exit code is zero or not. mocha test.js --timeout 1500000 Since documentation takes time so we have to mention time out while running mocha. If your test case passes successfully, you will get output similar to this. WebUi Generator ✓ exit code should be zero Resources: Getting started with Mocha and Node.js How to test JS with Mocha Unit Test with Mocha  

Continue ReadingTesting child process using Mocha in Yaydoc

Unit testing nodejs with Mocha and Chai

There are a lot of unit testing frameworks available for Javascript, Jasmine and Karma being some of the older and more popular ones. Jasmine and Karma, though are, originally designed for browser-side JS, and hence, frameworks like NodeUnit and Mocha have become more popular with server-size JS. We needed code coverage reports to work after the unit tests, and the Jasmine-Node reports were not sufficient, so we just moved to using Mocha. When using Mocha, we can use some assert library (which is not necessary, but makes life a hell lot easier). We are using chai at the open-event-webapp.. First of all install mocha globally - npm install -g mocha And write your tests in the test/ folder that mocha by default considers as the folder containing your test specs. For example we have our tests here - https://github.com/fossasia/open-event-webapp/tree/master/test Writing a simple mocha test is as easy as this - var assert = require('chai').assert; describe('Array', function() { describe('#indexOf()', function() { it('should return -1 when the value is not present', function() { assert.equal(-1, [1,2,3].indexOf(5)); assert.equal(-1, [1,2,3].indexOf(0)); }); }); }); The first parameter inside describe() is just to show the tests in a aesthetic way in the console. You can see our tests described in this file  - https://github.com/fossasia/open-event-webapp/blob/master/test/serverTest.js And attached below is an screenshot of the terminal after I have run the command mocha in the root of my project

Continue ReadingUnit testing nodejs with Mocha and Chai