[MUSIC] Because of JavaScripts dynamic type nature, coding in JavaScript can be an unconstrained experience, as long as you know how JavaScript actually works. But that freedom comes at the cost of missing out on the immediate nature of error reporting that exists in strongly type languages like Java. That's why testing your JavaScript code before shipping it off to your users is very important. You don't want to wait until the user calls you up and tells you that something is broken, just to discover it was as simple as a mistyping of a variable name somewhere. If only you exercised your code before calling it done, such errors could have been avoided. Modern day software development is rarely done without writing unit tests. It's simply a part of the process, so what's unit testing? Well unit testing is independent checking for proper operation of the smallest testable part of your application. Unit testing is a very powerful concept and there's a lot to this definition, so let's take it step by step. First of all, it's independent, it's important to isolate the small piece of functionality you're testing from the rest of your application as much as possible. First, you want to make sure you're testing just that small piece and not the entire system. There's a place for whole system testing but that's not unit testing. In unit testing, we want to verify that just this small part functions as it should, the rest of the system doesn't matter. Think of testing how well a car tire holds the tire pressure in a hot temperature environment. You wouldn't want to assemble the entire car just to test that, not only would that be very time consuming but it will also introduce other issues into the test that have nothing to do with the tire pressure. The smallest testable part of this definition should also hint to you that incorporating unit testing into your development process changes the way you approach the rest of software development process all together. In other words, you can't write functions that do 20 different things and then expected it to be small and testable. Each function or component you test, has to be focused on a single function or small outcome. Wrapping an entire application into one function that does everything, makes unit testing impossible, because unit implies small and focused. This is true of whether or not you buy into the purest approach of test driven development or not. Unit tests should also be written such that they're repeatable, this means that as you add more functionality to your code base, rerunning your existing unit tests and seeing them all pass should give you the confidence that your new code additions did not break some existing functionality. But what happens if your small unit of code has a fairly large and complex dependency? You still need to test just that small unit of code without the dependency, and the answer to that problem is mocking. Mocking is a technique where dependency and its behavior is imitated or otherwise just known faked. Mocking can be done directly by the developer or a mocking library. A mocking library will usually provide a more complex or perhaps a more generic interacting with some functionality that you're trying to mock. For example, if your component depends on the dollar sign HGP service that makes an Ajax call, you would need to mock the dollar sign HGP service. So that in your unit test you can fake a server response to verify the expected behavior of your component actually occurs. Now, you could certainly write your own unit test without any help from any other framework. However, it's easier to use a testing framework that comes with a bunch of tools to help you with set up of your tests. Providing methods that help you verify the result you got was the result you expected and so on. The Jasmine framework is a very popular JavaScript testing framework and one that works very well when testing Angular code. So that's what we're going to use to construct our tests. You can use Jasmine as a standalone browser based testing framework or command line one. In this course, I'm going to cover the browser based one but realize that using the command line based one would allow you to create scripts that automate your testing. And that's a huge benefit, not to be dismissed so easily, okay, let's go with the basic steps of using Jasmine. Step number one is for you to download and unzip the Jasmine standalone into some directory. You could download it from this URL, and it's a URL to the releases of the Jasmine test and framework. Once you downloaded and unzipped that release version, you erase everything in the src and the spec directories. Then, you place your own application code into the src directory and you place your test code or spec code into the spec directory. By the way, the reason we're calling our test specs is a bit outside of scope of this course. It has to do with our approach called Behavior Driven Development or BDD. Basically as you'll see in our example the test code will read like a specification of the functionality we're trying to test. The next step is to update the supplied html page which is called SpecRunner. And what you need to do in it is replace all the references to the erased src and spec files with the files that you yourself edit into those directories. In other words, your application code and then your testing code or your spec code. The last step is for to you to start something like browser sync or whatever you used for a local server. And go to http:// something, probably local coast:3000/SpecRunner.html and that web page will kick off running all of your tests. For the stand alone version of Jasmine, in other words the browser based one, and not the command line one, you could keep the browser sync running and then keep the browser open on the SpecRunner.html. That way you could see live as you code if the tests are failing when you think they should be passing. Okay, so how do we write this spec that we spoke about? Well, writing a specification or a test is fairly straightforward, you start all specs with calling the function, describe. This function is a container for all the tests we're going to run. Next, optionally, you can specify a function called beforeEach, the function value specified as the argument into the beforeEach function will be invoked once before each spec is run. This is very useful because before any test is run, we have to make sure that the conditions under which the test is running are identical to what we need them to be. If your code changed some data as a result of some other test execution, and then we ran another test thinking that our application is in a certain state, when it's not. Our results might be wrong, but either way certainly not reliable. So here inside the beforeEach function, you can initialize whatever data you need, instantiate whatever services you might need for each test and so on. The it function is the actual test, note how the whole thing, the describe string and the it string, read like a specification together. My function should not return true, now Jasmine provides a pretty extensive set of functions that you can use to test the result of your application code execution. Note that the function names are also designed such that it reads like regular English. In Jasmine, to negate a certain expectation statement you simply append the not property to it and continue calling verification statement. For example, here we're expecting the result not to be true. Okay, enough theory, let's go to the code editor and try out testing some simple functionality. Besides, I'm ready for some cookie detection code.
