Let's take a look at a real living breathing unit test, and you can see what it really looks like, and how it runs. Let's go back to JSFiddle here. This is another JSFiddle who dress you can see here in the video and/or you can find in the supplemental resources. There's no HTML. There's no CSS here, but I have gone and linked to a bunch of external resources. These all the various files that implement this Jasmine package or resource. You can just fork this and you'll have all these. The basic thing that's going on here is that we have a bunch of code that implements the Jasmine tests that's here. This will hopefully look familiar, our code that we are testing, which is in our case, check domain and get domains, and this is the code that we're going to look at for both unit and integration testing. This is the Jasmine output here, and this says, four specs, no failures, everything's okay, randomized with seed, and basically what you're seeing over here is the names of these various tests. I'm going to scoot this over. It's going wrap and look a little funny here, but the important part will still be there. I'm going to zoom in on this to make this a little easier to see and here we are. All right. Now, again, this is this function check domain, this is a quick review. It's getting as an input and email address, and its job is to return, yes, this email is okay. It's part of the list of domains or no, it is not. In its first line here, it goes and it calls get domains to get the list of domains. Now, just for dramatization purposes, I've gone through, and I've put gunk in the list of domains, and yet this is still passing. So, that's because this is a unit test and what I've done in the code above that implements the Jasmine testing as I have stubbed or marked this out, this particular get domains function. I have created a testable. So that the value that's ending up here is actually get coming from our test code itself. That's what we do when unit tests we're trying to externalize any dependencies and just test the individual function. So, let's walk through this Jasmine's syntax. Basically, Jasmine is a test suite for JavaScript. There are several. I like it because of the intuitive nature of the syntax though there are lots of good choices. If you use a language other than JavaScript, there are whole bunch of other good choices that may pertain to that. So, Jasmine may or may not be the right choice for you and your team, I would look at what technologies you're using, what things the team is familiar with, and just make a sensible decision on that basis. I've just chosen this because it's a reasonable option and I thought it would make for a good general example for you all. All right. So, with that prolog, let's look at this. So, the way that a Jasmine test starts is it says, describe and then we just pass in this thing in quotes as just a descriptive name. Make this a little bit bigger, so we can see. Okay. So here, we see this email domain validator that's coming from here. So, you can see these things are indented, subordinated to this, and these are the individual specs that we are running within this test. What I have here is a function that you can see that starts with before each and that does a lot basically what it says. So, before each of the specs that follow, we're going to implement this function that says, spy on get domains, this window thing is just to context that operates. If write JavaScript, you're pretty familiar with it. If you don't, don't worry about it. So, we're just basically saying, we're calling this function that's part of Jasmine that says, spy on, which has a bunch of things, but in our case, what we're going to focus on is that this is a way to create test doubles and we want to spy on get domains. This is a way of appending additional function content to this and return value whatever I put in parentheses here, which is our previous domain string here. So, what you can see is that this is a way we're saying, return the value, in other words, create a testable stub out the action of get domains, do that on each of these, and that's what makes this work. In spite of the fact that I put gunk down here, and they're actually, if we tried to validate any of the emails that you see here, this would fail, if we hadn't stubbed out. I'll show you an example of that when we integration tests. So, here's the first spec and it starts with this thing it. That's the function call and we put it in a descriptive name, validates emails from our domain. So, this is where I thought, "Okay. Well, let me first test the positive case. If we pass in a valid domain, it should work." You can see this is over here. This input we are putting here appears here is the name of the spec, and then we have this function that just says, expect to that, and this is this concept of an assertion, which we talked about, expect that if we pass in a talented alexandercowen.com to our checked domain function, that we would expect that to be true. We expect the output to be true and this is passing. Then, next I said what I thought, "Well, we should check that in fact, it invalidates domains that aren't on our list and this is my personal email address. This is from not a domain in our lists." You don't see Stanford alumni.org up here and we expect that to be false. So, this is really the same syntax except we have different argument, different email that we're going to test in this case, and a different outcome assertion that we expect, which is that it's false. Likewise, if we get something that's a badly formatted email, so like it's not a fully qualified domain name, in other words, it's just, for example, this word string Stanford alumni, then we expect the function not to breaking, we'd expect the result to be false because this is not one of our domains that we would validate, and then we're going to check here that this validates sub-domains from our domain is just a check that I thought, "Hey, why don't we do this?" Well, we'll check domain that isn't as a sub-domain, that isn't a simple careen.com, but instead also has a sub-domain in front of it and we would expect that to work, assuming that it is in our list, which in fact, it is. So, this is a unit test. It is specifically testing this function in an isolated fashion through the use of this before each thing that spies on it, and returns it always the same arbitrary value that we're going to use in our test code regardless, and that's an example of a unit test. If you want to go to this JSFiddle, and play with this, and make it work you can, and in the next example, I'm going to show you one that's a little bit simpler. You might find a little bit easier to get into and play with. But that basically is how we might unit tests with Jasmine, one other closing note I did this on JSFiddle, it's quite obvious to you if you're involved in this work. But this isn't really where you would likely run your actual unit test suite or integration test suite or system test suite. This is just an example you would probably, there's various ways to invoke these things, and put them in a certain place. In a high functioning environment, you will probably have a continuous integration, continuous delivery system that's going through, and calling all the various code that we would invoke to do this stuff.
