Ah, unit testing! It takes a multitude of things coming together to ensure that a team of developers write good automated unit tests for their work. One of these things is deciding on a unit test framework to use (it’s a bit of a maze out there). Another is making it really easy for developers to write their tests.
Unit testing can tend to be an afterthought, and the last thing you want to worry about when you are facing tight deadlines is having to learn a new testing framework on top of the pile of other tasks you likely have on your backlog. This chapter will walk through getting a skeleton unit test framework working in your project—ready for those important automated tests to be written. The examples in the chapter uses the Jasmine testing framework (with Karma as a test runner) within an Oracle JET project. However, you are free to use any unit testing framework you want with Oracle JET, such as QUnit.
Installing Karma and Jasmine
Karma Setup
Now that the libraries are installed, we can set up the Karma configuration. There is a command (karma init) that can set up this configuration file up with wizard-like questions. However, for this example, we will create and set up the file ourselves, to better understand what it is doing.
Create a new file called karma.conf.js within the UI directory. Inside the file, there are multiple options that we should configure. Let’s walk though these now, and the full code will be included just afterward.
When Karma runs, it will spin up web browser instances to run the tests, and the files that Karma will be loading into the browser can be set using the files attribute. These patterns are resolved using glob and will have the basePath appended to the beginning. The included: false attribute is required on some of the files, to prevent Karma loading them into a script tag within the browser, and, instead, they will get loaded by RequireJS.
The Full karma.conf.js File
test-main Setup
Now, we can move on to the test-main.js file , which is the replacement for the standard main.js file we include in the application. The test-main.js file will be responsible for finding and loading all of the ViewModels and test files within the application. (Test files must be named as the ViewModel name followed by -spec.)
The test-main.js File
Karma successfully running
Writing a Test
The ticket-desk-spec.js File
This is a really simple test for the onTabRemove function with ticket-desk.js. The code begins by loading the ticket-desk ViewModel within the define block, so that we can run tests against it. The ViewModel instance is initialized before each test from within the beforeEach function . The it block sets up a new test to check whether the deleteTab method is called from within the onTabRemove function, with the correct ID passed into it.
To run the tests, make sure the Karma CLI is still running and that the application is running too. When the files are changed, the Karma CLI should automatically detect changes. All being well, you should receive a success message in the Karma CLI and changing the key value in the event object to another number should fail the test.
When you begin to write more tests for your application, the reports are generated and stored within the UI/reports directory. These reports will give a breakdown of code coverage per ViewModel.
Overall coverage statistics for all ViewModels
Code-level coverage report for ticket-desk.js
Summary
In this, the final chapter of Practical Oracle JET, you have explored Jasmine and Karma. You have installed the relevant libraries and set the confirmation of Jasmine and Karma to support a JET application. Finally, you have created your first simple test and should now be in a position to write further tests for the application.