 Okay, guys, shall we start? So good afternoon everybody. Last session of the day, pretty exhausted I think, everybody. So here we are talking about automate testing with Behat, Selenium, PhantomJS, and Nightwad.js. So speakers, who are the speakers? My name is Nikhil Sukul. I am Senior Drupal Architect in 5G Solutions, a company based in Tune as well as US. I am working in Drupal Domain for the last 17 years, no, my overall experience 17 years plus. I am working in Drupal Domain for the last 9 years or so. I have with me Senior Developer, Drupal Senior Developer, Gaurav. Hi everyone. My name is Gaurav Bashpre. I am a Senior Developer at 5G Solutions. I am working with Drupal more than 5 years. So here we go. So guys, we all are here talking about testing. So let's say what happens when computer is not invented. How you to find the bugs? So when there were no computers, there were no bugs in computers. So everybody was having a plain slate. Anybody found any bug? No. Nobody found any bug because there were no computers at all. Now then we started building computers and we started writing the code for it. And when we started writing the code, bugs started coming. And bugs started coming with full force, based on the quality of code what we write. And then we deploy testers. We get the testers. And what the best thing about testers? See, the testers should not is not on his desk. So we can deploy code, hurry up. We don't have the will in on our plate, so we can always deploy and see the code. And that is not told in the job interview of any tester. Then this kind of situation will happen for a tester. Okay. And this is what happens when you are in support mode. And what you get is somebody in the middle, late show stopper, kind of a person who is a big tester headache, a kind of a bug with any tester can get whenever you are in a support mode and you get a late night call from a product manager that there is a big bug coming on the website. And this is what is said by a product manager or whoever managed the account that actually it is not a bug, it's an undocumented feature. Okay. So these are what we have for testing. So what is testing? So in general, testing is something where we are finding well how something works. So define what something works, what something works means what is being expected. So what is expected as per the software which is being developed as per the requirement of the software, what is expected if the testing is a process of evaluating that particular process and give you the expected output. So how we do testing? We do testing like this. This is a very good slide. You can actually take this slide and give to a client and he will be very happy. See receive the client documentation, prepare the list of scenarios to test and then we send across to the client. The client will say, okay, the scenarios are correct. If they are not correct, it will be keep on iterating. If it is correct, it will go to prepare a detailed test case plans. And then again, you go to the client, then the client will say, no, it's not working. Again, you will keep on iterating otherwise will say yes. And then you will say, voila, my test case is created and now I can execute the test plan. This is what generally how to do writing a test case and how to receive a documentation from the client. And then you go to the execution of a test plan. And why we do testing? What is the requirement? Why we do testing? So testings are good when you want to find a defect in development phases. So people will say, yeah, we do unit testing. But remember, unit testing is a part of test. We have to do unit testing. We have to do testing for whatever code we are writing. And it actually improves a lot for whatever functionality we are developing. It makes customer reliability and the satisfaction and for the application. So a customer becomes more confident with you. He understands that there are less bugs in your application. So he becomes more and more confident that my whatever outcome will be coming from the application will be very reliable, very quality friendly. And while you are testing, please also test for the performance of the application, the performance of the software. So testing is required when you do performance testing for an application. And while doing development for an application, if you are not doing testing, it is very expensive once you find it after the development is being happened. You all agree that once the development happened, if you have a fixed bit project, it is delivered to the client and the client come back with 10 different bugs. It is not in your scope for that cost. It is all beard by you because you haven't tested it properly on the first place. So generally there are three types of testing you can categorize functional, non-functional and maintenance. So functional means you have various kind of testing like unit testing, integration, smoke, acceptance testing, localization, globalization, interoperability and so on, these big numbers for it. Non-functional, which generally happens for every project, it should happen for every project if possible, performance, endurance, load testing, volume testing, scalability testing, usability testing of the application and so on. And then the last is maintenance. There you have regression testing and maintenance based testing, which generally happens based on the support plan. Now who will test your application? Somebody from this group? I don't know, okay. From here? No, I don't think so. From here? Yes, there are few people from here. Can you recognize the picture? Where it is taken from? Zupincon, Dublin. So there are some testers here in this picture who will be doing testing. So let's again categorize testing with respect to execution. So there are two types of execution. Now everybody is getting excited, we are coming to the real thing. This is what the session is all about, manual testing and automated testing. Excuse me, I am not going to cover manual testing at all. I am only going to cover automated testing. But yeah, let's compare it first. What is the difference? Or where the automation testing can be useful than manual testing? So automated testing is very useful with regression testing. Now think about a manual tester. I have a sprint going on and after a sprint he write the test cases and he did manual testing for 500 test cases. After two weeks, again a sprint need to happen, a hot fix maybe. And then the pert manager said, can you please execute 500 again? And this guy will say, I will take a beer first and then I will think about it. Because again I have to think of 500 test cases manually. So let's use automation testing there. And since he is doing manual testing, definitely it's a human testing so it will be slower. It won't be very fast. Whereas if you made an automated testing script, it will be far more faster. It is, automated testing is very good for build verification testing on short form as BVT. The initial cost of automated testing if you create any automated testing framework using the tools, it might be high. You might have to invest some money or invest some time for it. But after some time when you run it, it will be very cost effective. So let's talk about automated testing for this session. This is what happens when automated testing is actually from Stone Age. You can see that. It comes with a computer and it's still being automated the same way. Okay, so automated testings are two types you can categorize. One is the real browser testing. I don't think I need to tell about what real browser testing means. Everybody does real browser testing. You create an application, you open a browser known as C-H-R-O-M-E. Guys, it is Chrome. You open Chrome, you open Firefox, you open R-E. Don't open R-E, it's bad. So let's think of Chrome or Firefox. And those are generally used for real browser testing. It's a no-brainer. You create an application, you create a website, open the browser, do testing on it. You find your test there. You can see whether there's a error and you fix it. Then you have headless browsers. Headless means no head. So headless means the browser testing doesn't require any graphical user interface. Now this can be automated because it is not requiring you to open a browser. And you can actually do the testing or writing a script in headless which can do the testing for you. The examples are PhantomJS, ZombieJS and all. I love zombies. Yeah, really do. So what is the difference between headless and real browsers? Headless are faster than real browsers, definitely. Because I am not opening Chrome, clicking on the button and doing it is actually happening everything in the background. And you can actually, you can reduce the time of opening the images or CSS and all and to perform the actions in the background itself. Headless browsers are not representing real users. Yeah, so I won't be writing the headless browsers with the 500 users name. I'm only writing a headless browser with one functionality and say that please log into a particular system, check login is working or XYZ is working or not and give me the test case output of it. I won't be saying that Jack will be logging or XYZ will be logging. I can give, I don't have to give any names for it. So there's no real user who's represented for headless browser testing. Array detection in by the way in browsers are real browsers are easy-peasy because it is visual. You're actually looking at the browser and you can find out very easily where the bug is. Whereas in the case of headless, you have to wait for the reports to come out. So when the headless browser will do the background testing and the reports will come out, then you will see that there were ten test cases which were failed based on what functionality you have asked for. And headless browser doesn't support Ajax. I mean Ajax are browser based. So headless doesn't have a browser, so doesn't support Ajax. Anybody has idea what is this? Anybody? Yes? Okay, very close. It is Selenium Firefox plugin. So it's a Selenium IDE which is being used for Firefox. And it is good for those guys who want to start Selenium IDE or you want to start what Selenium does actually. If you install a Firefox plugin of Selenium, you can actually record all your functionality there. It will generate scripts in the background. And you can run the script again. It will record all the actions there. To the beginner, this is a very good tool. So what is Selenium? Selenium is a web driver. It's a collection of open source API and it is used to automate your testing web application. And above all, it is platform independent. It is one of the, I think, first automated testing web driver which is being used. Very popular web driver and it is very successful in its automated testing domain. How Selenium web driver works? So they are actually having, it is actually working in Java. So Selenium is absolutely based on Java. So it has their own interfaces which are written in Java. A class need to implement those interfaces. A class can be a Chrome class, a class, a driver of a Firefox driver. And those classes which are being implemented on interfaces can have their own functionality. So the Selenium web driver gives you an interface from which you can actually create based on your browser different interfaces. You can download Selenium from this link. It will give you a Java file, which means you need to have Java to run Selenium there. Gaurav, can you show that? Sure, I'm going to start Selenium server. So Gaurav, I'm going to start the Selenium server for you guys and show how Selenium starts. These are the basic commands which is Java-jar that driver name. So you can see, jar is a command to extract the jar until run in a particular port. So when you hit Enter, it will actually say blah, blah, blah, and say Selenium server is up and running. So now Selenium is running for you, right? Okay, let's go back. Sorry guys, we didn't test it this, so it happened. Okay, so next, talk about Behat. So I think I heard about Behat when I was working in Drupal itself because when there was a module for Behat in Drupal, that was the first time I learned about Behat and it was really amazing. When I saw that, I can write something in plain English, rather than writing a JavaScript code there. So Behat is an open source behavior driven development framework which is written in PHP and it's actually used a special language, English-like language known as Gherkin. So it's a business readable, specially behavior description, and it doesn't have any logic, it's more like a plain English. So think of a tester who doesn't understand any programming language, but know how to write test cases in plain English, and he wants to use an application so he can use Behat. He can write test cases directly in plain English in Behat, which will be converted into a machine language using PHP, which can be used by Behat to execute the test cases. This is an example of Gherkin, how to write a test case. So there are something like feature which is there in Gherkin, then you have scenario, some intermediate business situation, then given and when these are the keywords, you can use whatever you want and you keep on writing scenarios and based on the scenario, the PHP will generate a script for you automatically. So then next come is Mink. So Behat is a testing, so Behat is a testing tool. Now Mink is a simulator for that Behat. So Behat will give you an idea, this is an English-specific language, I can use Gherkin, I can write test cases. Now how to execute test cases? So those test cases will be executed if you use Behat with Mink. So Mink is a simulator for Behat to execute it on the browser. What is a browser simulator or browser emulator? It's an abstraction layer, so it's not actually a real browser, but actually giving you the feel it is running in the browser and running it the same way in any browser the things will work. So Mink supports with respect to browser both headless as well as in-browser capability. It is also having capability with single consistency and it is written in PHP 5.3+. You can download Mink and install with Behat, the link is available here. So let's show about Mink. So the first thing what we are showing here is Behat with Mink with headless, that is there is no browser interaction. So once you run it, what happening is it is actually giving a scenario. The scenario is written as Gherkin and what is happening? He is actually giving a I am on slash, that is the URL. When I will follow login, which is a button, I will fill username and password. These are the username and password. Admin address 123 is my own Gmail password. Please use it. Then we say login and then we say logout and my account. This is the scenario. It will attempt. Then again it will attempt another scenario with wrong credentials, bogus pass. What a wrong credential. Then again login and again my account. So it will say that for two scenarios where two passed, it will take 14 steps. It will execute everything and give you the output. Now this is headless part of Behat. Here is another one. Now Behat with real browser. So it is opening the browser in the background. It is logging the same credentials. Now both the credentials are written and then it stops. It was very quick. If you guys have seen it, I can't slow it down. But what happened was whatever was in the headless scenario is now being run by Behat using the browser. So the headless scenario works very well when you have a continuous integration engine like Jenkins or anything, where you can want to see the pass and fail. And Behat scenarios where you want to execute the test cases on real browser and check it out how it works there. So next is PhantomJS. Now what is PhantomJS? PhantomJS is a headless browser. So headless browser means that it doesn't have a browser. It's only a headless browser. But it also requires you a JavaScript API to write code to execute few things in that headless browser. So PhantomJS, you can download Phantom from here if you want to. And PhantomJS is good for headless website testing. Again PhantomJS doesn't have its own test runner, which means when you're executing PhantomJS is not going to give you pass or fail. It will actually execute few things like you can execute the test cases if you want to. You can do a screen capture if you want to. You can actually select the HTML element using PhantomJS and see how it is working. And since it doesn't have any test framework, it is only used for those kind of purposes. But okay, let's see Phantom first then we'll go for Casper. So let's see what Phantom can do. Okay, so can you open the folder of Phantom? So what happened there was, okay, let's for the people to see whether it is really working. Let us try again. Let's delete all these two images. We are trying to create the screen capture functionality with PhantomJS. Now if I go to the folder again, it is being executed again. Can you show the code of PhantomJS from where we have done it? So here what is happening in PhantomJS? You can see there are few objects available there, page.open, page.evaluate. These are JavaScript API available within Phantom.js. And what we are trying to do is we are trying to grab the elements from query selector like clicking the element, then give the name, give the password and click on submit. And it will again render the login page. Whatever is being output here, we are taking the screenshot of that and putting in the same folder. Can we show the screenshot? So this is what happened when you logged in in admin and admin credentials. We took the screenshot of that and the second one. And this is what has happened after you logged in. So one is before login, you took the screenshot, took in the credentials and one is after login. This is what PhantomJS is doing with just JavaScript API. Now you might have seen, I haven't used Selenium here. I have only used PhantomJS. So PhantomJS doesn't require Selenium to run this thing. It can run it standalone by itself. Now what is Casper? Now CasperJS is built on top of PhantomJS. And what is capable of? This can be used as a test running tool. When you run CasperJS, it uses the same kind of PhantomJS APIs. On top of it, it can actually give you the perception of pass and fail. Currently what we did, we just did the screenshot, right? But we want to know after admin, whether it was done pass or a fail scenario, you can capture using CasperJS. Okay. So here what's happening? I clicked on Casper underscore loginJS. It is actually using same PhantomJS script. But on top of it, it is having its own wrapper for Casper. Once I execute it, it's giving me the scenarios. Pass, pass, pass. M3 were passed. It took so much amount of time. This is being done using CasperJS, which is run on top of PhantomJS. Now show the script. Now using CasperJS, if you see, they are using similar kind of assert exists. These other assert exists which are available in CasperJS. Rest everything are based on the API available in PhantomJS. So based on that, we are running it. And based on this, we are getting the output of a test case. Now, lately, I actually went through a session which was given in one of the Drupal con for nightwatch.js. So there are so many other tools which are available. Nightwatch.js is also one of them. Now what nightwatch does is actually based on Node.js. It's an end-to-end testing solution. And it has a big web driver API. All these are good. But the major aspect for nightwatch.js is it is used for real browser testing. It is not headless. Like CasperJS, PhantomJS, which are headless. Nightwatch.js is real browser testing. It is used along with Selenium. This is the architecture of nightwatch.js. So it has a test script. It has a test runner. It takes the Selenium and the way we were talking about the web drivers of Selenium. It takes like that, runs based on the web browser. So it's a real browser testing framework. I'm going to show demo. Now let's see the nightwatch demo. So before that, nightwatch, once you install, it gives its own executable, nightwatch. Then you can give the command for DrupalLogin. T is for testing. Then DrupalLogin.js, whatever you have created. Then json is the file. And c stands for configuration. So it's a real browser testing. It will open the browser. It will again log in. Once log in, it will say, okay, this is already being passed. Then it's going to second section. It's going to give the bad username password. And it will give the assert. And then it becomes a total. So it's a real browser testing with respect to nightwatch.js. Now let's see the code of nightwatch. So for nightwatch, you can write something like this. We have given pause deliberately so that we can show you clearly what's happening. But in night browser, it is very much JavaScript language. It is being written. And it has a very simple way of writing the code. It grabs the thing the way you can see elements are getting grab of HTML. And then it is being executed. Okay. So all this what I have just told you, it's a bit confusing. Few of them are headless. Few of them are real browser testing. Few of them are both. Which is what? What to use and where? So let me go through it. Okay. This will be, we'll start slowly. Okay. Let's start one by one. Now pay attention here. It's a GIF. Okay. I can't control it. So one, two, three. This is headless browser. I am giving a notion. This is real browser. Okay. They are dancing. B hat plus Ming plus Selenium all goes to real browser testing. Okay. B hat plus Ming plus Selenium goes to real browser testing. If you come together. Night watch plus Selenium goes to real browser testing. They are any way real browsers. B hat plus Ming plus go to driver. Goes to headless. They are again headless. Okay. Fourth one. Phantom and Casper. They are headless. Right. B hat plus Ming plus Selenium plus Phantom goes to headless. Okay. Come on. Done. Now go down. If you want, I can try one more time. Just for your information. Let's try again. Okay. Headless browser and real browser. Please dance. Okay. B hat plus Ming plus Selenium goes to real browser testing. Okay. Yeah. Got it. Next. Night watch plus Selenium goes to real browser testing. Because night watch is real browser testing. Okay. Third. B hat plus Ming plus go to driver. Goes to headless. Okay. Fourth. Phantom and Casper. Headless. They don't have any head. B hat plus Ming plus Selenium plus Phantom goes to headless. Sure. Come on in. Yeah. That's it. Okay. Yep. Always goes to a real browser. A very last example where it's Phantom. So this evening we've seen Phantom. Just one more browser control. Absolutely. I really like the observation. So there, Phantom is already a browser. Selenium is already a browser. Yeah. A web driver. So you can either use Phantom or use Selenium. If you install both, it doesn't matter. It becomes a headless browser. Very good observation. Yeah. Because I have a covered PHP unit. Whatever I have covered, I just took that. For that, I have another session which I will give an afterwards about PHP unit and simple unit and other things. But I will touch separately for it. Yeah. So for a while, like two months later, nothing worked. Like the drivers were no longer compatible with the current version of the browser. Was able to sort that out. The project was installed for a couple of months and the same thing happens. Like the drivers are no longer compatible with the latest versions of the browser. So I find that we need that to catch up. And in the end, we just decided to go on, like in the Damian package manager, go to an operation and try to work with operation of the Selenium driver. And the drivers in this case were like the browsers. So how do you catch up with all the latest versions of everything? Like I know it's a little bit different. Yeah. So how do you keep up with that? So I think we keep up the same way the way Drupal.org keep up with the latest version. We need to keep up updating the drivers whenever, as soon as they come. But in my opinion, based on whatever we have seen so far and what we are using, we are going towards more on JavaScript-based browsers now, phantom.js and all rather than only dependent on Selenium. Because Selenium is a Java-based browser and it requires a Java-based setup for everything. If you go for something that doesn't require a Java-based setup and you can still do the work, it will be better. And this way we are more working towards phantom.js and all the others, which doesn't require Selenium as necessary. Okay, so we did that. If you have seen, we run the same test in Headless as well as the same test in the browser. The difference was that there is a message for wrong user which was coming. I was giving a bad password that was coming within the browser itself. Whereas in the case of Headless, it will be a pass-off scenario there. You can see in the command line. What's the difference? Yeah, I understand. Don't worry when the YouTube will come to pause it and slowly go through it. It will be easy. Yeah, I think the main reason which we are tempted to go for Headless is the complexity of a project and when we have to do regression testing a lot. And I still believe that we should do the first round of testing as manual for UI, if possible, because you see the visual changes very clearly. Okay, otherwise I think it will be really good if we can do the manual testing or the way it is being done, opening the browser and closing the browser thing. But using Jenkins as a continuous and empty engine, it is better to use Headless there. And then you get the test cases and see the pass and fail what is happening there. My vision for this session was because when I was keep on trying to get various Headless as well as the real browsers sessions across the board for various places in internet and never find any session which is talking all four about it. It is always one single place for one single technology. And I was really getting confused. So I installed four and say I will give all four. Give from my side. Be happy. Yeah, so I think if there is a session of Night Watch in Drupalcon, which has happened by that person. If you see that, he is actually using Night Watch to call browser stack from an API. That is possible because they are real browser testing. And then from the API, you can execute it there and you get the check results. So we have tried that and it works with respect to that. So I think that's the way it works for browser stack. No, it's not so complicated at all. Sorry. Yeah. But this is Night Watch, right? So Night Watch was using an API from browser stack. Yeah, Selenium Viya, which is actually doing that and getting the things. I haven't tested with API. I haven't tried it, but I will do. Anybody else? Thank you.