Thanks, everybody. Thanks to JSconf. I'm going to try the first part of this slide is holy going to be entertaining and some other started stuff.
So, first of all, a great big thanks to John Charles who is a teammate on the team who got this spot and then gave it to me. He's not here. He had to leave early. And then he sent us this picture and he was actually not wearing a shirt. So I did everybody a favor and really quickly put a shirt on him.
He has so much chest hair, it looked like he had a sweater on.
Also it has been a long conference and for those of you who have families that didn't travel with you, I'm sure you miss them. I miss my son and daughter the movie star. Max gets two pictures because she's something. That's him trying on my shorts.
Look a lot alike.
So another kind of reminiscence, I grew up in the '80s, and there were aspects in the '80s that seem to never happen and that's the thing nostalgia, it's only later on when you look back and pick that out as a time period and say, you know, this thing looks pretty special.
During the '80s I was trying to think it wasn't going to happen because the culture felt wrong in a way.
But in any case, like the future, hear cops will wear Toms winning no socks. And they will drive Ferraris. And there will be a music channel devoted to videos. And people will dress up in the desert.
Star Wars movies will be good.
My point I sort of like made it. Part of my point is when I get a few drinks in me, I pick something like this and try to defend that, so I just want to bring that to you that happened a couple nights ago.
So let me move on to what has happened in PayPal since we started using node JS. It came in as a prototyping framework, so some people came over from Netflix, and they basically said, hey, we want to transform, you know, what's going on at PayPal in a lot of ways, and the part of that is the technology. So let's see if we can build a product faster with node JS than we're able to do with Java. So I'm not going to go into great detail, but the result was that we started developing all of our product, all of our web on kraken JS.
If you weren't here for Dave Cadwallader's talk earlier, he showed the test sit at the top, that's a great pyramid, and I agree with that as well, UI tests are important they shouldn't sit on top.
So why should you test? Well, let's take an analogy. So here's John again and this was a golfing excursion that I wasn't on. So we use golf for product development, and these guys who went golfing are some of the best develops we have at the company. So let's say they're the best golfers that you could possibly have. So they went to the golf course with their golf sticks to knock the ball into the goal.
So here's them starting out. They're having a great day. They're developers. Look at that. That's beautiful form; right? So, you know, they're great. They shouldn't ever make any mistakes because, you know, you're going out, you're golfing, you know how to golfer. Well, sometimes you don't have your best days. Maybe you stayed up the night before or you're just a little bit distracted, so mistakes get made. And sometimes side effects get introduced into your code.
Anyway okay. And here's Jeff taking a swing.
So why test? Well, even great developers have their days when something gets through; right? So that's why test. Oh, and sometimes it turtles end up on the golf course as well. Moving fast for a turtle; right? Okay. So let's test finally.
So what Nemo does is sits around that, it's a wrapper that basically gives you some tools for configuring that web driver and also gives you a plugin capability so that you can kind of make the system that you need. It's nothing but giving you the tools that you need, and we're going to look at some of the plugins that I've made that I think make the most sense. But the idea is anybody can come in and do their set of plugins that they need to do.
So the plugin that you use primary is called Nemo view, which we're going to go into. And, you know, other plugins, so whatever you want to put in there. Whatever you need kind of thing.
So at this point we're just launching the Web driver, the browser, and running commands, but you have to have some other test like cucumber or something.
But, again, Nemo isn't prescribing what you use, it's just saying here's the piece of it. Now you use your test runner. We like to use Mocha. And then on top of that you use a test runner, and at PayPal, we've been using grunt, and obviously for private projects �� at least not in PayPal it's not heavily used yet. And I've heard of one called broccoli, but I haven't gotten into it yet.
So you need these components to make a full automation solution.
So, again, we're going to recircle back. What does Nemo do? It loads JSON configuration, which is used within kraken as well. Basically it does JSON, but it does overrides, and it also has short stock handlers, and it gives you a lot of dimensions of control when you're doing your configuration.
So Nemo also takes that configuration, and it starts the Web driver. It initializes your plugins, and provides you access to that whole Nemo ATI, and it gives you the name space you get the dot driver and the dot DWP, which are the two components of the web driver API.
So let's talk about for a minute just to explore how the configuration works.
So config gives you something [Indiscernible] the variable in your environment and determine sort of what overrides get used in your configuration. On top of that it uses something called a short stock, and short stock handlers, it is also built by the kraken team, and these would be values that you put in your JSON that if a handler is encountered �� so let's say JSON value has its handler N, then short to being is going to look in the environment for this variable and replace in the JSON that value.
So the shortstop handlers do various things. There's N, [Indiscernible], RV and config, that take your JSON, make it a lot more intelligent, and give you some control over your configuration.
So what your configuration directory might look like is you have your main config dot JSON and you have your specific override files, it just depends on what you're doing, what those might be. And to give some sense of what the configuration would look like, just your basic configuration tells the driver to launch this browser. And then there's the plugins and the data properties, which are optional, but we'll get needs to a bit by the later.
And then what's my sauce user name, my sauce key, and you can see we're using the N shortstop handler so on your local machine you've got your key there, but it's not detecting source control. And snowmobile another cloud based testing service, and they use a different set of capabilities. IOS driver, the same thing. Just basing giving the driver different stuff to contact the different driver.
So really quickly we're going to do a screen cast. Hopefully you can see if you're sitting a bit by the far away. I'll try to zoom in if it makes sense.
This is an example that comes in the Nemo compository, and here we're getting a constructor, and if you look in that directory its pointing to, there's a config dot JSON, and it's got a �� the driver section and a browser section.
So Firefox opens up. You get a little printout that says what test do you want? Firefox.
So if we set the node environment variable to special. So this time we launch phantom JS just by resetting the node environment variable. And that's because in this special.JSON, we're testing phantom JS. So that's to get the [Indiscernible] environment override.
So the next thing is notice that there's this shortstop handler here that says config colon browser, and that's saying look for this configuration property and get that value. And another feature of shortstop is if you have something at the base of your JSON, you can override it with a RRRV or environment variable, so we're going to that he is the using Chrome and launch Chrome instead. You can also set an environment variable of browser and do the same thing. So this is just a little something that I wanted to show you.
So that should launch phantom JS so we should see a browser open. And then just kind of drive the point home. If you use both at the same time, if you use an environment variable of browser and an [Indiscernible] browser, which one would take precedence, and I think most people would say that the RV would take precedence, which it does.
That is just a quick intro to how you can do cloud overrides in shortstop handler in the business within Nemo.
The second major component of Nemo is plugins, so let's talk about those. What would be in a plugin? You might have web driver abstractions, so some common things that might make sense together. You want to share it between projects. Or if you're a company that does stuff internally for testing, you might put proprietary, or you get a setup function has a simple signature of taking the Nemo object and a call back, and then you add something to the Nemo and name space. So, for example, Nemo dot log in is saying when the Nemo object gets solved, we've got this Nemo in this case it's a function so I'm going to log you in and there's a comment that says this is the web driver stuff that will log you in.
So that's basically when a plugin looks like. And if you want to configure a plugin, you just log in and say it's somewhere in my path or [Indiscernible] in this case it's in the file path. And to use it, once you've got Nemo resolved and back to you, you just call it Nemo dot log in and you pass whatever parameters, and that's how you author register and use plugin.
And the plugin that you authored to be sort of our, you know, favorite or promoted web driver abstraction is called Nemo view. And if you look at the �� here's sort of three levers. The first level is what you would do in basic web driver to find an element to click on it.
The second line is what you do with Nemo view if you use these under score methods that just take I simplified locator, basically we're providing a CSS locator, and then you can click on it.
And then the third level is if you use the locator abstraction, which will name space set to locators, so in this case Nemo.U.nav, so these are the three layers, and I think you would agree that the third is more palatable than the first.
First of all, this is the Nemo view with the module, so it would look like this and you say I have this new plugin, and what it gives you by default is these basic abstraction methods that you supply different screen to, and you get your element back.
So there's fine, fines present, visible weight, and first visible, the last two are the ones that I used a lot for a sync testing, so that way you don't put ten seconds in between this command.
So, for example, this is adding the bank in the sample application that we're going to see in a minute, and I'll just kind of leave it there for a second so you can take a look.
So the next layer, if you're not the just using the generic abstractions is to say I want to have a set of locator files to store my locators so that they're shareable across files and locations. So I'm going to specify this argument to Nemo view it. It says look in this directory, there's some files that you should be interested in. So there's this located directory that you should look at.
So here's an example of locator file. It's just simple JSON and you can see it's got a type and a locator, so this is just defining elements for in this case a bank, a bank form. So there's a number of routing buttons, and then success and failure, and we'll see how they're used in a minute.
So this is what it looks like to add a bank using that view. So you're �� you're setting a couple of convenience variables and then we're using the Nemo view methods to work through that UI.
So let's really quickly �� this is about a five�minute demo. It's going to basically cover those points that I covered, and we'll just do it again using the sample app. This is something you can clone right now and MPM install and just get it running. What it is it's called pay friend, so it's a mini�PayPal application and it looks like one page application behavior, so it gives you a few second wait in between each activity, so you can say fail.com and log in, and it will do the test.
And then there's a couple of forms of adding the card and the bank and all those have those success and failure scenarios.
The 100�1001 is the failure number and then anything else is the success, and you can bring it back out.
So what we're going to do is we're going to walk through the timeline of how you would test an application. So, for example, the configuration again. But when you first start testing an application, you're just kind of writing the test on the fly. You're just throwing the script together, so it would look something like this. Where your locators are just until file, it just looks like a big functional script, and this is what it looks like. You're using the generic meths to run through the UI, to log in, add a card, add a bank account.
So we're going to run that, and it's using the Mocha runner on web storm. And it just runs through all those scenarios.
And you can use any �� you don't have to use CSS locators, you can use ID locators or any of the other available Selenium locators.
So the next step of testing an application, once the UI starts to harden a bit by the, you say I want to start taking these locators out and I want to start putting them in a location, and that's where we would start using locator files. So, again, we're telling Nemo �� or Nemo view rather to look for these JSON files in this directory. We've got �� this is bank card, log in, and nav. So this are basically in my mind when I put this election up, those were the four parts of it. And here's all the locators that you would need.
And this would be the next step of the testing process. We're now using the locator files instead of the generic method. So we're using the log in view, the card view, the nav view, and the bank view to run the test now.
So I'm just pointing out that there's an e�mail locator and then all these functions that are built off the e�mail locator, so it's loading and it will wait until it says that element to move on and do these other things.
So we'll run the view based one, and I didn't mention �� well, I did mention it, but we're using Mocha to run these tests, so utilizes Mocha around the Web driver commands.
And it's all going to work because I like to stay away from the demo demons.
So that's basically a walk through of the Nemo view and the way you would about it from the first test to the third where it's packed in a nice way and usable.
And just a reminder, at this point is that this is how I train people to use Nemo within PayPal. This doesn't mean that's the way you have to use it, Nemo, again, is just a simple web driver application that allows you to do plugins and do the configuration that we talked about before. So I have seen, and I'm looking forward to seeing, of other examples of how to use it and people have their favorite modules and tests around it.
And to get started to look at that stuff and to play around with the code we looked at today, have you just to clone the Nemo example app, and we're looking for contributors �� and I didn't mention it at the outset, but Nemo was actually named after captain Nemo, the scary guy, and not the fish.
So what we're looking for is help for, like, fixing the generator, it's not generic enough, so I didn't want to promote it today. It does do things, but not to the point where I want to talk about it. Some mobile examples would be notice, we heard about Magellan earlier today, but we would have to look into that, and I think that's my last slide.
Ask me for a sticker. I've got stickers up here with a little guy on here. So that's it. Enjoy the conference.