OpenJS Foundation OpenJS World 2020, 26 Jun 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Workshop: Test all the Things with Intern - Jason Cheatham, SitePen

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Hello and welcome to test all the things within turn during this hour-long workshop I'm, going to give you I'm going to introduce you to the intern testing tool, describe some of its capabilities and show you how to use it to test a simple react application in a couple different ways. This workshop doesn't assume that you have much experience, writing tests or really any experience, but you should be familiar with JavaScript or typescript if you'd like to follow along open a terminal and make sure that you have at least node and NPM in your path.

A

You'll also need Java installed. If you want to run some of the test that we write later, the tests aren't actually written in Java, but one of the tools used by intern selenium is written in Java. So you need that to actually run those so first off a little bit about myself and what I do I am a software engineer at site Penn at site Penn. We are the co-creators and maintain errs of the dojo toolkit and we're also the developers of the new modern dojo framework, along with several other open-source projects, including intern.

A

We also run the first typescript focused conference, ts Kampf, which is on its third year this year. I am also the lead maintainer of intern, so you know I try to keep things up to date. Keep you know manage releases if you have feature requests or bugs those will likely eventually land with me. So it keeps me busy and then, in my spare time, I really like to work with home.

A

Automation like I, have basically I have a couple of home automation, hubs that I've set up and I wire up, like all the lights in my house and electrical. You know, switches I, have a variety of sensors for like temperature and humidity and pressure, and all that just sort of scattered around, and you know, I come up with interesting ways to use that so like on a good day. I don't have to touch any lights, which is in the house.

A

It's it's a learning process, though so you know that doesn't always work, but but it's really awesome. When it does it's. It's neat to see code. You know working with the physical world.

A

So what are we going to do today?

A

The goal here is to give an overview of in turn and kind of show you some of the things you can do within turn, so we're gonna, you know, set it up right, several kinds of tests, but it's only an hour, so we can't go into a lot of depth, so I'm, mostly just going to be giving quick flybys of how to write a few different kinds of tests- and you know again just show you some of the things that you can do so first off, let's get into what actually is in turn, so obviously it's a testing tool.

A

It was originally created for the dojo toolkit several years ago, when dojo was making its switch to AMD and heavier use of asynchronous code. Things like promises when you know back in the early days there, and so they you know, one of the site pen engineers then created in turn to be a more effective way to test that kind of code.

A

Probably interns key differentiator right now is that it supports the full testing lifecycle. So, with intern out of the box, you can write unit tests, you can write function to functional tests and full psych integration tests and we'll go into the difference in those a little bit more in a couple of slides.

A

Another differentiator is that intern really focuses on testing and real browsers, so it can use I mean it can run tests in node and that's what it does by default, but it also tries to make it easy to run your tests in browsers.

A

My intern can also collect code coverage, so you know to help you know how well your unit test you're, exercising your application code and it's it's extensible. It's pretty easy to write plug-ins for, and there are a couple of existing plugins. It will look at later on today and it's pretty easy to plug in turn into CI systems as well.

A

So when we talk about unit tests and functional tests, unit tests are the ones that probably most people who write tests are familiar with. Those are tests that load application code and just call functions in it directly. You know instantiate classes, work with them and look at the output again just directly from the code, and we like to say those those test code from the developers perspective. The other major kind of test is functional tests. Functional tests actually sort of sit outside the application. They don't load application code directly.

A

They don't you know, see it or touch it. Instead, functional tests act a lot like a user and the access they exercise. You know sort of the user level functionality of an application, so a functional test might tell a browser to load an application page like I'm, going to load some web page, and then it might look on the page and find certain elements.

A

It might find a button and tell the browser to click that button and then look at some output, or you know some text in a field to see if it changed so functional tests test code from a user's perspective. Instead of from a developer's perspective,.

A

So when we talk about how we organize tests and in turn, we have three sort of broad terms there at the top level, our suite these are groups of tests. That are, you know it's a logical grouping. So very frequently a suite is, is created for a particular module. Let's say so. You know you're testing the button module in your application, so you would make a button suite and then put all the tests for button in there.

A

But you know you don't have to have just one suite for file that can be multiple and you can nest Suites. So if you want to have finer grain groupings you can you can do that tests are the things that actually exercise code or maybe exercise the browser and make assertions so I mean the test. Is the thing that's actually doing the work and then test can be asynchronous, so they can work with async code. You just return a promise and in turn, that's that's the basic async unit and within test the checks.

A

You're actually making are called assertions. So when you do something like you know, you you, you call a function and look at its output. You're gonna make an assertion about its output and you're, going to check and see that something is true. Maybe maybe you call a function, that's supposed to append something to an array. You get back the array and you would assert that the length of the array was one bigger.

A

Then it started out in turn provides the chili Brer II, which is a popular third party assertion library, and it gives you a lot of these high level assertions like asserting that the length of something is something you expect or asserting that a value is true or is null or things like that. You can also just write your own assertions. Basically anything that you know the only thing an assertion has to do is throw an exception if there's a problem. So if you, if you check a condition and it's bad, you would throw an exception.

A

Otherwise you know you don't and when you use something like chai, it's just it's making that process a little cleaner and easier to read. So we provide that, but in turn is very flexible about actually what you use there.

A

So, let's kind of get started on this and jump right in here and take a look at what our test application is, and you can see this down here we're going to be getting something from this intern tutorial repository, so first off, let's just clone that I'll go in there and we're checking out the open, J's world tutorial branch. So we have that and then we're just going to install our app it's a standard. You know, node application created with create react, app. Well, I!

A

Guess it's a react application, so we can just run npm install. It should also work with yarn I, just use NPM all the time.

A

So once that installs we will be able to run NPM start and that will start up the application in the development server and open it up in a browser here and then we'll be able to take a look at it and you know see what it does as soon as this finishes. Installing it's not NPM is never the fastest thing: okay and we're good. So we've cloned our repo installer thing we're running start, and so here we go our application and all of its glory is a calculator.

A

It's you know a standard, simple little multifunction calculator, seven plus three equals ten. Hopefully it's good. It's not a thoroughly tested calculator which you know is fine for our purposes, but it makes a nice and it's nice and interactive and has easily extractable logic.

A

So, let's take a little closer look at what's in our flashy calculator here, real quick just because it makes testing a little bit easier. Okay, so in here we have, you know the standard react layout. We have a public directory with our static assets. We have a source directory that has all of our code in it and in our code here we have components and just a couple other things we don't have any further breakdown in our code, because this is a very simple application. We don't need a components directory and a you know, etc.

A

So we have our capitalized components here. We have two other modules we have common, which is just some typescript types and I think one constant, and then we have this logic module here, which is where the the logic that actually you know handles things like, plus and minus and equals lives.

A

Let's take a quick look at our code, so if we look at our calculator code here, it is a react component. It's a functional component, so we just were exporting a function. That is our component within that we're using some react hooks here to create some state variables and some things to update them. So we have this. You know value total and operation.

A

We have this button, args thing that we've made down here- and that is just all of these- these six variables up here- we're just sticking them in an object. We will use these with the logic that actually manages our buttons.

A

This button handlers thing is just binding: the names of keys on the keyboard to particular button handlers, so that we can also use the keyboard to do things as well as click buttons. The button handlers themselves come from this button handlers, constant and there's just one per button, so AC goes with the AC button. Divide goes with, divide x, goes with x, etc.

A

We can see down here. We have a couple of new event handlers.

A

We bind the the keyboard handler to the entire window, which is not maybe what you do in the real world, but for this tutorial app is fine, and then we create our calculator component, and you know it's just it just contains a simple. You know a wrapper div and then within that the display and the grid of buttons, and then you know the buttons get passed a callback and the current operation.

A

Okay, so we have the basic idea of our calculator here. You know I mean this is what the component looks like the buttons and the display or similar kinds of things. Let's take a quick look at the logic module, so this is where our button handlers live and basically in here we're importing a constant which is just a list of button names and then we're importing a couple of types, and so we're just exporting from here our handlers and that's just an object that is basically binding.

A

The name of the button to its handler, and so the handlers are all just functions that take a button, args object and that we saw in the a calculator component.

A

The button args are this thing, which is just all of these state variables and they're there updaters.

A

So each of these handlers takes a button args and then pulls out the properties that it cares about with destructuring here and then does whatever it needs to do to update the calculator state. So all clear, we'll set the displayed value to 0, and it will, you know clear out any pending operation plus minus divide, just mix that dot will look at the value and if it has a decimal in it, I will do nothing if it doesn't have a decimal in it.

A

Dot will add a decimal to the end of the number, and you know the rest of our of our button functions are in here. So this is what kind of what we're working with here and what we're going to test, and so, in our case we're just assuming you know, we have an application. You know nobody wrote test while it was being made, but now we're gonna write. Some tests to you know prevent regressions all right.

A

So before we can write tests, we got to get in turn in here and kind of make sure that that's working and so to get in turn we're just gonna npm install it. Let's save dev wow, that's installing. Let's go ahead and edit our intern config file, the intern config file is just a JSON file this you know it contains intern configuration options and we need one of these in our project to tell intern when we run it that hey.

A

This is an intern project and we're going to set it up right now to point to where we eventually plan to put some unit test, Suites, so we'll say, test unit any TS file under there note that we can use globs here for the sweets list and also that we can put TS files directly in here, because when we are running our tests in node in turn can take typescript directly. You don't have to pre, compile it. So this is our simple config file.

A

We just finished installing in turn up here, so let's actually check that it worked. Let's run NP x in turn, when you install in turn, you get an intern, you know binary script and your node modules bin directory, so we can just NP x in turn, excuse me and it ran, and so this is the expected output in this case, because we have no test yet so it ran tested zero platforms. Nothing passed, nothing failed, so we have in turn.

A

The next thing to look at is in turns interfaces in turn provides three of them they're all functionally equivalent. They just are different styles, that you can use when writing your tests. So the first one is the TDD style. This one is just very straightforward: you create a sweet with a sweet function, you create a test with a test function and you make assertions in general with the assert syntax. You know assertion yeah. So that's that's.

A

Basically the TDD interface and you can see at the bottom of the TDD section here that this contest equals internet plug-in business. That is how you load an interface and a test. You know that the interfaces exist as plugins and in turn, and so you're just requesting this plugins exports from in turn. So that's how you get that and the same thing with assertions in this case we're getting them from chai.

A

So the BDD interface is another one. It's you know. Behavior driven development is what BDD is. Td is test-driven development, so the BDD interface is exactly the same as the TDD interface it just uses described and it instead of suite and test and the idea there is just more it encourages sort of an English or you know like a language flow.

A

When you talk about the Suites and test so you're describing you know a resource, a module, a suite, and it should do something, and it should do something else, and you know that sort of thing and it is common with BDD to use the expect syntax for your assertions. Chai supports both of these. It provides an assert and a set of assert functions basically, and it also provides a set of expect functions and these again are functionally equivalent. It's just one under different styles.

A

So with BDD, it's normal to use, expect you don't have to you. Can you can use assert with BDD and expect with TDD it's pre flexible and then the third interface is the object interface. This one is kind of an intern, unique one where you don't use, describe an ad or Sweden test instead, rather than using functions to make your Suites and tests you you create your entire suite and an object.

A

It's a very declarative interface, so you make your suite and an object and when you've constructed this object, you pass it to this register suite function and then that goes ahead and takes care of processing that into runnable Suites and tests and with object again. The assertion syntax is pretty flexible, usually I've seen people use assert with it. You could again totally use expect with it all three of the tests. Syntaxes supports, suite lifecycle functions so with all of them.

A

You can use before before, each after and after each so before, each and after each run before and after every test, in a suite before and after run once at the you know before, runs at the beginning of the suite before any tests have run and after runs at the end of the suite. After all, tests have run so these are functions you can use to do setup and cleanup for individual tests or entire Suites.

A

All three all three tests interfaces also support. Async functionality just return a promise from a test and your async. You can also declare test to be async if you want to use async await for any of these, so let's go on and actually write a unit test.

A

So when we're gonna write a unit tests, the first thing we need to do is create a typescript config file and the first thing we're going to do is create a typescript config file in the test directory, because the tests are going to need actually first we're going to make a test directory.

A

Then we're going to may write a TS config file in there, because the tests are going to use a slightly different set they're going to slightly different options, and then the TS config file that the rest of the app uses we're going to inherit from the base one, because most of the options would be the same.

A

Alright, so the options that we're going to change are we're going to set our module type to commonjs and we are going to disable this isolated module, setting that that the react, TS config uses and we're going to load the intern types, because in turn, declares one global that we want to have available so that we can do things like internet get plug-in types in turn, all right: the isolated modules, basically we're disabling that so that we can write Suites that aren't technically modules.

A

I mean we might want to write a suite that doesn't import or export anything. It's completely fine. But if we don't disable that setting typescript will be sad about it all right and then we need to include our test files in you know with this TS config. So we're just going to say anything under the test directory is handled by this TS config file, iscope config room there we go alright, so we got our TS config file.

A

Let's update our intern dot JSON file. We need to get that ready to we're going to add the TS config that we just created to this node section, and so what we're doing here is you know, I said earlier: intern can process typescript by default and it can and it uses the project default, TS config by default, and so, but that's not the one we want to use.

A

We want to use our tests, one so we're gonna, say: node TS, config, test, TS, config, dot, JSON TS config goes in this little node block to make it very explicit that it only applies to a node environment. Intern, like I said, can run in browsers and it can run in node.

A

You use the same config file for both I mean you don't have to, but it's pretty common to, and so within this config file you need to tell you know in turn, needs to know which things apply to browsers in which things apply to node, and in this case we just wanted to make it very clear that TS config is really only a node thing, browsers, there's no typescript processing functionality for browsers all right. So we got that we've updated our config file. Now we should actually write the test.

A

So, let's see we need to make the unit directory and test because we said we were going to put our test and test unit in turns pretty flexible about this. You don't have to put your test in a test directory or in test unit. You could put them in your application directory and call them. You know dot spec files, if you want it or something I normally just put them in a test directory, because it seems cleaner to keep your test resources separate from your app.

A

But it's very you know it's very flexible about how you actually do that all right. So, let's edit test unit we're going to test the logic module so the eye test unit logic. So let's go ahead and import our interfaces, we're going to use the TDD interface, so sweet and tests equals internet, plug-in air phase TDD and then we're going to import the assert.

A

The assert interface from chai okay, so we have these so now we're going to make it sweet and we're going to call it logic.

A

And we're going to write a test for the AC button handler, so let's go ahead and call our test AC all right. Well, the first thing that we notice is we're: gonna have to import the AC button handler to be able to test it. So, let's import the button handlers from source logic.

A

Okay, so we have that a button handler Stacy just try to call that. Oh yeah ac takes an argument. We saw earlier that it needs something of type button handler args oops. Let's just go ahead and import that interface to.

A

Handler ours, that's one of the things, that's in that common module all right. So let's make an arse, that's of type button, handler, args and so button handler args take some value. It takes set value.

A

And we'll just do this.

A

Then it also takes total, which can be null or a number and then we'll just have set total.

A

And then it takes an operation which can be an operation, just a string or null and then we'll have set operation, and it takes an operation which we should also import from up here.

A

So all we've done here is made basically a mock of our button handler args and we are just you know they. They have the value of the total in the operation state variables. We have the setters and they're just going to update those variables in the state, so this will make it very easy for us to pass in something that you know that's under our control and then look at how it changed. What, after we've called the function, so we're going to pass this in and now typescript is happy about it.

A

Okay, so now we can call our function and we're passing it something and we're you know we actually want to run a test. So what is AC supposed to do? And if we go look at it, it's supposed to clear the value and clear the operation. So let's check that that happens. So, first we're going to set the value to something and we're going to set the operation to something we're going to call this function and then we're going to look and see if they actually got a got cleared. So we're going to assert that.

A

That our value is zero and we are going to assert that our operation.

A

Is null, and so, if you notice well, you know, as it quickly popped up when I typed assert and hit period there's there are many many assertions that you can make using chai and again the the main value of all these I mean these are things you can do yourself with just code and if statements, the value you get from using these assertions and chai, is that it's more compact and easier to read and also chai will construct friendly or at least useful exception messages for you.

A

So we'll look at that in a second, so we made this test. Alright, we've made our assertions, we call our function, so let's actually go down here and run it so we'll just run in turn. We've already pointed it our test, so it should run our test and it did. In the note environment, we ran the logic suite the AC tests, one test passed.

A

If we wanted to see what happens if it fails, let's jump over to this AC code, real, quick and you know make it do something wrong. So let's say it sets the value to negative one. Okay. So if we run our tests now, it's gonna run and it's gonna fail and the failure we get is au is an assertion error. We expected negative one to equal zero, so this is try constructing a nice sort of useful error message for us.

A

We can make that even more potentially contextual, if we want, we can add a message here at the end. So maybe incorrect, you know- or we could say, expected, AC to clear value. So now, if we run the test, I mean it's still, gonna fail, but now we get an even more contextual message here expected. You know, expect AC to clear value. We expected negative 1 2 equals 0.

A

So try. Let's you make. You know meaningful, meaningful assertion messages, so let's just fix that and make sure that our test passes again, and so this is our first unit test and it's running a node and there you go okay, so we ran it in node, but one of our big things is being able to run tests in the browser.

A

There's a problem, though, which is that we can't run typescript directly in the browser. So what are we going to do for that? We got a couple of different options when you're using a react, app or something that's normally built with web pack. Web pack is probably the most straightforward way to go about that. The goal there is just to bundle up your typescript and everything it needs for its test into a JavaScript bundle that we can load into the browser.

A

So to do that, we're going to make a minimal web pack config and we're going to make a couple of a little updates to our project and then we're going to build that and run that. So, first, let's we're going to need the TS loader since we're going to be web packing typescript code.

A

We need that we're also going to need the web pack. Cli. We've already got web pack from react scripts, and you know normally, you shouldn't normally rely too much on you know transitory or a transient package dependencies like we're doing like we're going to do, but it's just a little simpler in this case. So we're just going to install the CLI and it will work with the web pack that we already have so.

A

Let's install the web pack CLI and TS loader and while those are going we're going to edit our web, we're going to create actually a web pack config and in our web pack. Config we're going to import resolve because we're going to have to resolve a couple of paths.

A

We are going to export our config.

A

All right so load development, because webpack needs that now for our entry for our test in general, it's going to be most efficient to just build all of your unit tests that you plan to run into a single package. There are other ways you could do this. You could build them into separate packages and use you know like vendor, chunking or somesuch.

A

For our case, we only have one tests, but if you do have you know even a moderate number of tests, it's entirely possible to just build them into one bundle so that they'll run so we're gonna run test unit, logic TS. So this is going to be our entry point, for you know what we're gonna do with it is. We are going to compile it to a file name called unit J s, because we're assuming this is just all of our unit tests. The path is going to be.

A

I'm gonna put it in tests in the root and the project root directory.

A

Okay, we have to set up what we need to handle typescript.

A

So for this we're going to say all right if we have a TS file or a TS X file, we're going to use the TS loader we're going to pass it a couple of options, we're going to tell it most importantly that it needs to use this config file. That is our test. Ts config file.

A

Turning big Dutch cheese on, we also want to change another compiler option, specifically just for web pack and that one is no omit. The react config, which our test config is inheriting from enabled this no omit option for our own purposes. We don't want that, so we're going to turn that off here, and this will just allow this simple web pack config to build our stuff.

A

So we close this. We close this. We close rules and then we just have to tell web pack that you can resolve typescript modules or typescript files. Yes, ts, XJS JSX, so none of this is really so much in turn specific as it is it's web pack but yeah. This is. This is sort of the minimal minimal web pack config for our simple react. Example here: alright, so we got this.

A

We don't want that semicolon. So now we have a web pack config.

A

We install TS loader installed web pack CLI. Let's make sure that our web pack build works, Luffy X web panic, okay tests, gotcha. Yes, so if we set things up right, this will run and it will give us something in that test directory and it did so now. We can build our unit tests.

A

Ok. Now we need to tell intern that it should run our tests in a browser, so we're going to edit our intern config again and then our intern can fit we're going to add a new browser section, and in this browser section we are going to tell it which Suites we want to run in the browser and they will be tests unit Jas then we're gonna move this sweets declaration into the node object. So the deal with that is when sweets is up here. It applies to both the node and browser environment.

A

So when you're running a node, you will get whatever sweets are here and any sweets in this node block. If you're running in a browser you get whatever the base, sweets are plus any other sweets in browser.

A

We're just gonna. Stick this in node. This means that we are only going to run these sweets in node, which is fine because nodes, the only one that can process the typescript and we're only going to run these sweets in the browser.

A

So now we've told intern what we want to run in the browser. Now we need to tell it what browsers we want to run these things in, for that we use an environments, property. The environments property just tells in turn. What environments we want to run. Our tests in by default is one environment and it's node we're gonna, keep doing that and we're also gonna add another environment, chrome, okay, so we have two environments: let's go ahead and run our test and get in turn.

A

So now, what we should see happen is where we're seeing this listening on localhost, that's in turn, starting a test server for the browser to load the test from, and then we see it's starting a browser, and we saw this stuff happening.

A

This stuff that is happening is, in turn, running feature tests in the browser to try to see if there are any any bits of functionality in the browser that are maybe operating in a non-standard way or that are broken or something because different browsers, don't always work exactly the same way in turn, tries to look for some of those differences and deal with them behind the scenes, so that you don't have to make a lot of fiddly adjustments to your tests.

A

That can be a little bit annoying. Sometimes though, so, if you want, if you're sure that you're using a modern browser- that's probably implementing you- know current engine jeaious specs pretty closely, you can disable those feature tests, and for that we can just use a slightly more.

A

You know long longer, syntax for specification, specifying our environment, and we can say browser, chrome, fixed session capabilities. We can set it to true false or no detect either. One of these well, you know, for our purposes, should be fine, we'll just set it to false.

A

No detect basically sets some some internal properties if it happens to know something about a browser that might be broken. Like you know, ie ten doesn't support this feature in turn. Maybe doesn't even need to test for that it just it's like. Oh, this is ie ten. We know this is broken. That's what know detect us, but in general Chrome should be fine, so we're just going to disable that and the whole purpose of disabling this right here is just it makes our test run a bit faster in the browser.

A

So now, if we run our tests, we will see them run in node here very quickly and we'll see our browser pop up. It will run the tests and it was much quicker that time there was. None of you know the feature test running beforehand.

A

All right, so this is pretty cool. Now we're running our tests in node, we're running our tests in the browser in turn tries to make it easy to run your test kind of everywhere. So, in addition to you know what we're doing now, we could add other browsers so say we could on Firefox.

A

Okay, so now, if we run our tests, we will see the node test happen.

A

We will see Firefox pop up and our test will run in Firefox, so that's pretty sweet, so we can run in different browsers. We can also run on cloud services. So if we wanted to in this case we could say all right- we're going to use this tunnel variable to use a different, basically a different target. So what the tunnel is tunnels are a thing provided by an intern support library called Dig, Dug and tunnels are what intern uses to talk to remote browsers.

A

So by default we're using the selenium tunnel that uses a local copy of selenium to talk to Chrome and Firefox, and you know the browsers. You have installed locally. We can also hook up to cloud testing services and we can use a null tonal, which basically tells in turn. Don't don't do anything. You know I've I'm running a webdriver, server or selenium sort of externally on my own. Just talk to it. Don't try to start your own, but let's try. Let's try using browser stack just to kind of show that you don't really.

A

You know it's pretty easy to do that, so we're changing. You know it's gonna one line of config here and we're saying we want to use browser stack.

A

We're also going to set up some capabilities here that our browser stack specific just to make it a little easier to see them. I was going to show them in the the browser stack dashboard. You don't have to do this, but we can whoops. I can look up exactly what those are again. Let's set our build name to, let's set our build name to Oh jsw and let's set our project named internal tutorial and again. These are browserstack, specific properties that we're setting this capabilities.

A

Property are like these are settings that get passed to whatever browser or remote session that we are starting. So that's just what goes in capabilities, it's kind of a random metadata grab-bag. So here we're saying we're going to run tests on browser stack and this again entirely optional. It just makes it a little easier for us to see what what's going on with browser stack.

A

Another thing to keep in mind is when you use any of these cloud services, you do need to have an account, so you'll need your own credentials to do that. This little Artest thing that I'm throwing in the beginning here is just a script that I have that loads up, some of my credentials into environment variables, so we're gonna go ahead and run this and we will see it. You know it's tunnel downloading and downloading the browser stack tunnel executable.

A

It runs a node test and then startup is a little bit slower here than it was for the local test. But you can see that popped up very quickly, actually relatively quickly, and so it was a remote session, chrome 83 on Windows. If we go over here and we refresh the dashboard that I have open, we don't see any builds.

A

A

There we go okay, so this is our test run, that's running right now and we can see we had Chrome and it ran and we had Firefox and it's still running, and so with browser stack, just as an example and the other services work. Similarly, you can give a browser name and it just picks the most recent version and usually on Windows.

A

You can also specify browser versions or ranges of versions if you want to run on multiple versions, and you can also specify the OS that you want to run tests on, so you can do all of that. Just you know within this intern config.

A

So this is us running tests on browser stack, so that is pretty sweet that we can do that, except for our Firefox test, which finished, but our session didn't quite end. Oh there, it goes okay, Firefox a little slow to finish there anyway. So so, as I said, you know, all of this, this tunnel system is provided by by Dig Dug. That's the name of the intern package that handles that and it has again several tunnels.

A

So there are a couple more tests. We can do as well, actually I mean there are functional tests. We haven't done any of those yet so for functional tests. You know, I mentioned those before the big deal about those is they involve browsers, but they don't run in browsers, and so this is just sort of an overview of what our functional testing API looks like. You can see here that we're getting this remote object passed into the tests.

A

All tests and in turn, are passed something they're passed a test with a capital. T object, one an instance of test, but usually you don't need anything on that. So we don't. You know it's not usually shown. In this case, though, we do need this remote property from the test, and so the remote is what's going to give us access to our functional testing API. The functional testing API is provided by an intern package called Leadfoot.

A

It's called that because when it was originally created it was a lot faster than any other webdriver API. It's not not much of a difference now, but it's still called Leadfoot, but so Leadfoot s-- api is an asynchronous fluent. You know a chained api, so basically from from remote, you will call something like get to load a webpage. Once you have a page, you might call like fine by CSS, selector or fine by name. There's a variety of fine functions to locate elements.

A

That's a thing you might want to do once you have an element, you can interact with it with, like you know, clicking, and then you might also I mean you can get information from elements like in this example. We're getting visible text.

A

You'll also notice that there's this end thing sitting in the middle of the command chain. What that is is because, excuse me so in our command chain, you need to find elements and interact with them right, but all of these commands are in a single chain. So how do you decide? What you were interacting with in turn in a single chain maintains a context element and the context element is kind of the the basis for what any following commands are going to.

A

You know work from so if you want to interact with an element you you find it and then it becomes the context element and then you, you know any actions you take, that are element specific like clicking or getting text or something those are done on the context element.

A

The context so in turn can can manage multiple context, elements and they're stored in a stack, and so you know when you, when you do something that's on the context element if you want to sort of back up and work on a previous context, element or just get rid of the whole context, and just do something with reference to the entire page, you call end and end just pop something off the stack, so that's kind of what's going on. There is so we find an element. We do something with it.

A

We call end to wipe that back off the stack and then we find a new element and we do something with it and then we can make assertions we don't need to have an end at the end of the command chain, because that whole context, business is specific to a single command chain. So you know once once we return this thing. We're done with that.

A

Another thing to really keep in mind is that the command API is asynchronous. So the end of that command chain I mean it's. It's a promise chain basically or a promise like chain so for in turn to wait for that. To finish, you need to make sure to return that chain.

A

So yeah, that's that's the thing that I've seen and done myself forgotten to do because then your test starts to look great.

A

It's like oh, it passed and then you'll see weird errors popping up later on in the testing process, because those promises started failing or something, and it's it's not good, so you always want to return a command chain, but that whole thing can become a little bit easier if you use async await so here's the same set of commands using the functional test API, but just using async, await instead of the fluent command chaining stuff, and for this you can see we we call a get to get a page and we just await it and like when we look for an element.

A

We, you know the fine by CSS, selector method returns that element, and it always does here we're just awaiting it. So you know when that asynchronous call resolves, we get the element out of it. Then we can call a method directly on the element. So here we can, you know, get the button and then call click on the button. We don't have to deal with the contact stack or popping things off of it or whatever.

A

So it's a little more verbose because we have awaits everywhere, but it is I think a good deal cleaner to see you know to deal with to see. What's going on, it's it's a little more straightforward to work with, so this is just another way of using the functional API that can potentially be cleaner, but you know either way does work.

A

Okay, so let's write a functional test so to write a functional test. We are going to make a directory and test called functional and we're going to write a functional test just for our whole app, so we're going to call test, functional, app dot, TS and we're going to do the whole.

A

The whole importing of our suite and test fit again suite test from I'm gonna. Remember that one of these days plug-in interface on TDD assert, equals.

A

Okay, all right and then we say suite app and we see a test we're going to test padding to numbers. That's going to be our first test, so that will involve some button clicking and looking at the output. Add two numbers: okay, so we got a remote object.

A

Okay, so in our test, the thing we're going to need to do is well. The first thing we're going to want to do is load our test, page yeah, we're going to call this a sink, so we can use async/await and we're going to say remote that get our test page.

A

Then we're going to want to get some buttons and click them. So, if we're going to add two numbers- let's, let's add one plus two and make sure that they equal three, so let's say 1 equals remote, find by CSS. Selector button is 1 so for this app. If we just go over and inspect it, if I can see where my inspector is here, we can just go look at our buttons and they all have. You know their class names our button, the name of the button.

A

Ok, so we got the 1 button, let's go ahead and a weight, 1, dot, click alright, and just because this will run really fast when we run it, let's go ahead and throw in asleep in here just for us humans, so that we can see what what's going on when we're clicking these buttons.

A

If we don't I mean we don't you, you wouldn't normally put this sleep in here and generally sleeps and tests are not a thing you should do, but in this case, like I, said it's just just for the humans to be able to see this happening, because otherwise it just goes by very fast, alright, so, oh and in between clicking 1 & 2, we need to need to click +.

A

Ok, so we click 1, we click +, we click. Now we need to click equals.

A

Ok and now we need to read the display and see if it has the value we expect.

A

And the display is just called it uses the class display.

A

Value equals weight, displayed, get text, oops, okay, visible text all right, and now we're going to assert equal value, and one plus two should hopefully equals three all right. So we have a functional test. Now our functional test gets a page, it clicks some buttons and then it reads the value from the display and again this is, you know, all sort of um a human centric perspective. The way the things we have available to do are in general, what a person looking at this web app would be able to do.

A

We also need to make I think one more change to our intern JSON file. Well, we need to make two changes one. We need to tell this thing that we have some functional Suites, so those are functional.

A

Even though functional Suites only applied a node, we don't actually put them in the node object. That's just kind of historical inconsistency at the moment, but yeah functional Suites only applaud a node if you load this config in a browser. The browser, the the intern and the browser is smart enough to know that it can't run functional tests. So it just ignores this.

A

We also want to specify a functional timeouts.

A

This is necessary because it didn't used to be necessary, but it has become necessary and I just haven't, put a default and intern yet, but the idea is when you do these functional commands like gets and finds, and such there are timeouts so that if you know you make one of these calls and it takes too long, there's a timeout. This is managed not by in turn but externally, by selenium or webdriver, and so they used to have reasonable defaults and for most browsers now, there's zero and so with a zero time out.

A

Most of your things will start to time out pretty quickly. So it's good to set some defaults for these functional timeouts, but again, future version of in turn will do that this particular thing automatically all right. So we have functional sweets. We have functional timeouts, we have our tests, let's see if it actually works. Oh yeah, let's also disable this browser stack, but another interesting thing is in turns: config file is JSON, but it's sort of an extended JSON that supports comments. So you can comment things out in an intern config.

A

Let's also comment out one of our browsers here again, just to make this a little bit faster. So if we run our tests now, we're gonna see our unit tests run in node, we're gonna, see Firefox pop up, we'll see our unit test result happened and then we're seeing our buttons being clicked right now for our functional tests, and so even with the one-second Waits. That was a little snappy. So if we open it up again just to kind of catch it again, we see browser.

A

Now we see it click, one click plus click to click equals and we're done, and so we see this test pass.

A

So that is a pretty simple functional test and just like our unit test, we can run our functional test on browser stack or on sauce labs or whatever, on different combinations of browsers and operating system. So we can basically ensure that our application is behaving the way that we want in all the combinations of things that we needed to run in.

A

In addition to you know, basic functional tests in turn has a couple of you know: pre-built plugins, to run other kinds of you know: functional tests, async excuse me, accessibility and visual regression. Test and I mean these are pretty simple implementations of these tests, but they are enough to handle simple cases and they again kind of work out of the box there. So just to give you a quick taste for what those look like, let's go ahead and install the packages, we would need for those, let's grab the intern Y and the intern plugin.

A

So again, the accessibility one is looking for accessibility checks so, like you know, missing alt tags and an image element for example, or things like that it uses. You know there are a couple of different external tools in turn, users to do that. One is ax, which is a local library. One is tenon, which is a cloud service that you need an account on the other.

A

You know our visual plug-in tests here does simple visual regression testing, and so it will basically take a snapshot of your page and then later, when you run tests, it will compare a rendering of your page against that snapshot and if it differs, that'll tell you so are you know, quick and dirty test for these? Well look pretty much like. What's on the slide there? Let's just call this one, a 1:1. Why check mate.

A

Wait stop check, you need to pass it the remote and when you have to give up the source URL that we want to test, which is the same thing we're using for our functional tests up there HTTP localhost 3000.

A

We do need to import that ax and deal so that we haven't actually I. Think the I think the import is called services from.

A

And then this is services, X, ok. So this is an accessibility test and let's go ahead and throw in our visual regression test 2.

A

And in this one, this one's a little interesting because we have a helper function that actually just writes the whole test for us, and you know that creates the test function for us. So from this plug-in we are going to grab visual test.

A

Ok and so here we're just going to call this visual test and it takes a URL which again same with this one, and it takes this missing baseline property, which is telling it what to do sort of in the initial case. If there's no baseline, should it you know whine about that, or should it just take a new snapshot so we're telling it take a new snapshot.

A

Parenthesis there. Ok! So now, we've added a 101 Y or accessibility and visual regression tests and again these are just very basic tests using these these two already existing plugins that exist for in turn. So if we run these tests just go ahead and do that both of them actually, the accessibility test will fail. The visual test should pass by default. The accessibility test is going to fail for the same reason that react has been whining about us this whole time, this missing alt text.

A

So if we go look up here, we see that our accessibility test failed, a violation was logged, but our visual test down here was fine. So let's go take a quick look at our at what happened there. So we have this accessibility report.

A

So if we go look in this accessibility report, we see that there is an html5. This is our report. If we open this.

A

Oh, what did I do? Oh there we go sorry, it was Firefox. If we, if we open our report here, we see that it's telling us what was wrong, that the app logo image doesn't have alt text.

A

So if we go into our app where we have our image sure enough, there's no alt text and again es Lent was whining about this. The entire time so probably would have caught that with our current tooling, but you can certainly imagine situations where wouldn't so. If we just add an intern logo, alt tag tag there and we run our test again.

A

We will see that our accessibility check passes.

A

All right so that passed as far as the visual test goes: that's testing visual code, so you know we haven't seen any violations with that. Yet if we go induce, if we change some visual aspect of our application, for example, let's go change the size of our little intern logo down there, and let's do that in actually, let's just remove it. Ok, so now the logo is gone. So now, let's run our tests and see what happens.

A

Okay, so we can see it doing the functional test. The a11y test was fun, but now our visual regression test failed. Okay, so we have you know we can see up here. Error failed, visual regression. We have this visual test directory that gets generated by the dividual regression plug-in here, and it has a report. So we can open that report, not the a11y report, the visual test report, and if we open that we see down here this red vertical, you know line business.

A

That is what it looks like when the visual regression test is highlighting the problem, and so the problem is right here and in this case it's that thing is gone. So again, it's a it's a simple, visual regression test. It's not you know you won't be able to use it for super complex situations, but again it is sort of an example of what you can do with in turn. Just with writing fairly. You know straightforward easy to use plugins.

A

So hopefully this has given you a reasonable overview and I know it. Wasn't. It wasn't in great depth, but hopefully you've gotten sort of a sense of what you can do an intern and at least how to get started with it and how to approach using intern, and so here we have a number of resources. We have links to various places where intern information is. The intern is the main website with links to all of the sub projects, and it has all the you know: project and API documentation.

A

We have. The intern is the main repo, the intern, visual plug-in and a11y, or their own repos. There choi jae, s's api is what we use for assertions, and you know we mentioned browser stack and so all of the web services have their own versions of this. But this is where browser stack describes the different capabilities you can years like we passed in that that project name and build name. There are a variety of other properties you can send into browser stack and they're described there.

A

If you have questions or you need help, there are a couple of good resources. There's the get er channel for the intern. I am always on there. So you can always ask questions there, and you can also always ask questions on Stack Overflow using the tag intern. So hopefully this has been an informative workshop and if you have any questions, feel free to ask. Thank you.