 So this is the talk titled Test Senior Critical JavaScript, my name is Nick Smith, I'm a senior software engineer at Sidecar, it's a startup in center city doing machine learning, I'm on the UI side, I don't have any opinions or really touch machine learning or AI, so don't, I think it's super great technology but I know very little about it. Also personal news, I welcome to Babyboy in the beginning of September and it is incredibly true what they say about the lack of sleep you get. I started this talk when Baby was born, I thought paternity leave, this talk is going to be amazing, finished it last week, took four times as long as I thought it would. And also a lot of people have been linking at the beginning of their slides so I just threw this in here. This is at github, github slash github.com, hopefully another website, futon which is my handle and then testing critical JS. There's a link to the slides there as well as a whole everything that I show here, the code samples are there as well. So the whole point of this talk is to give you the encouragement to start testing JavaScript. Your front end, giving you a whole overview of kind of what that looks like, give you the tools to succeed in doing that and also give you some broad guidance when writing your unit tests. While you might already have unit tests on the front end of your code, this hopefully will provide some more framework around that and help you avoid some gotchas that have gotten me. Before we dive in, we're going to kind of discuss what are all these terms around JavaScript and around testing and let's define them before we dive in. The first one is JS, JavaScript will start easy. Next one is business rules which kind of got talked a lot about in the last talk. Last talk was a great setup for some things that I'll point to moving forward. Business rules, any decisions you as a developer have made that affects your user's interaction with your application. For example, if you're validated in input in the last presentation, there's a lot of talk about filling out a form. There might be specific validation for one of those form inputs. That's a business rule you're deciding, you're deciding how that form input will get filled out. URL parsing, if you land on a page, you parse the URL or you're parsing the URL for the user to go to a different part of your application or your website. That's also a business rule you're deciding. I'll slow it down a little bit, sorry, I'm talking fast. Framework, a collection of patterns for development solving a common software problem or group of software problems. The product I work on is called Connect. We have a framework of how we build React components in that framework. We have a framework of GraphQL queries that we write on the API side of that application. We have a framework of how to approach and solve those problems. There's open source frameworks like Jest that we're going to talk about today and Jasmine and React and WordPress at some point of it is a framework. Suite, specifically testing suites. There are groups of tests that verify a software program and show that it passes a specific set of behaviors. We're going to look at hopefully some great examples. Hopefully you think they're great. We're going to look at a bunch of these. A unit test. It's testing of individual functions or classes by supplying inputs and verifying outputs. Almost all tests are doing the tail end of this. Given inputs, they produce these outputs. That's what we're testing. But a unit test is the smallest part of that testing of all testing. There's also snapshot testing, which is a newer form of testing if it can be known as newer. A lot of this is hot within React where you're doing snapshot testing with Jest. But you can snapshot test your homegrown APIs that output HTML, your Angular components, you can do that as well. We'll also look at an example of this. There's a great example on the GitHub repo that I posted. Integration tests could talk a lot about the difference between unit and integration tests. But for the sake of it, we're going to stay closer to unit tests. Integration tests are testing multiple units of code together. We were a little past integration tests in the last talk. We're about to get to what tests those were. But integration tests might be testing multiple units of code together. That might be a function that calls a function as an integration test. Testing a function correctly, writing to the database, that's an integration test. And outputting data into a static file, that's a really easy integration test. A lot of the previous talk was about end-to-end testing and automated testing. So end-to-end testing is testing the entire flow of the application. We have tons of end-to-end testings on the application I work on where we, in the CI we actually have an application that clicks through the entire site, verifies that a query gets sent to the API, writes to the database, and then we then re-query the API to get those updated values. We basically make sure the whole application works. Luckily, the talk before this covered all of this. So just re-watch that video. Automated testing, also covered by the previous talk. Doing any and all types of testing automatically, that's basically all it means. People use Travis CI or Jenkins, the previous talk used Circle CI, which is another great tool. And then lastly, we kind of just want to broadly define testing, probably going to redefine it five times. But it's all going to be the same thing, we're validating your business rules. We're having repeatable outcomes against expectations. And given inputs, expect these outputs. So we've kind of entered the first half of the title of this talk, but let's talk about what your critical JavaScript is. And it's, lo and behold, all of your JavaScript, which isn't a helpful answer. But so let's break it up a little bit. It's the code you're about to write, the code you're writing now, or the feature that is always breaking. Nine times out of ten, it's always the feature that is always breaking. That's your critical JavaScript. My mom always used the analogy of a storm for any life problem that I came into. So you're either about to enter a storm, you're in the middle of a storm, or hopefully you're coming out of a storm. So take it for what it's worth, maybe a life lesson you can take away from this talk as well. In terms of where to start testing, it doesn't matter where you start. But it matters that you start now. You need to start testing some function on your front end if you haven't already set that up. But let's make sure we do it right. So start small. Don't set out to test the whole UI. At a previous startup I worked at, I wanted to introduce some type of linting to the whole front end. So there's a bunch of popular solutions. I chose ESLint for that. But instead of studying out to test the whole UI and get it all linted at once, I started with one file, then worked the entire directory that that file was in, then the entire directory that that directory was in. And slowly built all the way up until it took about a year. We got the entire front end linted effectively with rules that made sense for our team. So pick a bug, function or feature. But don't get overwhelmed. It's easy to see your entire front end as untested or tested wrong or just not useful to be tested. But pick something that might not, that seems trivial and start there because it won't be trivial by the end. Love repeating myself. Start with the unit test. I think that when you're getting into JavaScript testing, it could be a single function, class or module, but just start testing it thoroughly and correctly. We'll get into the thoroughly and correctly here in a little bit. The important part is just to get the ball rolling. However that might look for you, maybe it is just a bunch of mistakes, but at least start the testing and start doing it. My, one of my other passions, which I could talk an entire talk about is getting