In Jasmine, there are three keywords specific to the testing framework that we need
to know. The first is describe; describe is like a class in testing. It groups our tests in one container to be referenced later. In the previous list from our application spec, we can use New Customer data test as our describe value.
The second keyword is it; it is a Jasmine function that takes two parameters, a string that we use as our test description. For example, one it test could contain a description such as Customer's ID should be a number. This tells the user reviewing the test what exactly we are testing for. The other parameter is a function where we can inject code or set up code if needed. Remember that all of this is being run in the same page, so if we would like to change any variables, or prototypes for a test, we can do that within this function before we run our test. Keep in mind that, while writing the test, we don't need to modify our code in order to test properly; this is done only in case we don't have a code sample for review.
The last keyword to remember is expect; expect is a function specific to Jasmine that takes a value and compares it with some other value. In Jasmine, this is done using the toEqual function that is a part of the expect function. Think of each test as readable like this: We expect the typeof newCustomer.customerID to equal a number. Now this is pretty simple if we think about it, but what does that
look like in a spec file? Well, if we look at the following screenshot, we can see our
Application Performance Testing
[ 178 ]
Here, we can see how our tests are written; on line 2, we have our describe
keyword that wraps our tests in a single container should we have a larger test file.
All our tests from our documentation spec can be found with each it keyword; test
number 1 is on line 4 and, on line 5, we have the first test's expect keyword checking the newCustomers.CustomerID type, where we expect a number.
Note that the type being compared is using a string rather than number, as you would expect in a console. This is because typeof, the JavaScript keyword for returning the type of a variable or property, returns the type name using a string; so, in order to match it, we use strings with the type name here as well.
We can see on subsequent lines that we've added the remaining tests using the same style of comparison for each of the other tests. With that done, let's open the SpecRunner.html page; we can see how our tests did in the Spec List view in the following screenshot:
Yikes! Three errors here, which is not good at all. Here, we were expecting a single error with the name of the customer not being displayed properly. But, our unit test has discovered that our application spec isn't being followed as it was written. In the Jasmine framework, this page layout is pretty common; on initial load, you will see a full error list. If you wish to see the list of all the tests that passed and failed, we can click Spec List at the top, and we will see the full list as shown in the preceding screenshot.
Chapter 10
Tests that have failed here show up in red on your browser, and those that have passed show up in green. You may also see green circles and red Xs indicating how many tests passed and failed in both the Failures view and the Spec List view.
Fixing our code
With our test code working now, we can modify it to ensure this works properly. For this, we will need to update the 10_01.js file and the newCustomer data, which is on lines 56 through 63 in the 10_01.js file. Let's review what went wrong with our
sample customer data:
• The first test that failed was 2, which required the customer's name to be created as an object array, with the first name as an array item followed by the last name as the second item in the object array
• The second that failed was test 3, which required the customerBalance to be a type of number
• The third error was test 6, which required the customer's marriage status to be a boolean and not a string
Let's update our newCustomer data; you can see that I've done that in the following screenshot:
Application Performance Testing
[ 180 ]
Once we've updated the newCustomer information in our 10_01.js file, we should
be able rerun Jasmine and retest our code sample. If all tests pass, we will see the default Spec List showing all results in green; let's reopen our page as shown in the following screenshot and see whether our tests pass:
Nice, all six specs have passed! Great work! By ensuring that all our application's data is using the correct type, we can also ensure that our JavaScript application is not only performing well but also performing with a high degree of accuracy, as it was intended to be used.
Chapter 10
When applications deviate from the developers, design, they can cause performance issues and affect the overall stability of the application. In Jasmine, we can see the
completion time of the test; note that the performance on the final test is much faster than the one with errors. In the following screenshot, we have our final application