Methods that we don't need to import in order to use them.
The group of related specs
Receives two parameters:
- The title of the expectation
- The assertion, in the form of an anonymous function TIP: To read the title of the spec, include the word "it" as part of the sentence
Return true or false. It has two parts:
- Actual value, or main parameter of the expect
- Chained with a matcher using dot (.) e.g. expect(calculator.value).toBe(5)
With this option the spec will report as pending and won't be executed. This is useful in two common cases:
- When you making changes and you want to disbled them until you finish.
- TDD -> You write specs first and then you create the code.
All specs within the disabled suite will be marked as pending (not executed).
Official Documentation: https://jasmine.github.io/api/3.4/matchers.html A boolean comparison between the actual value and the expected value. A matcher is responsible for reporting to Jasmine if the expectatin is true or false. In other words, if the spec is passing or failing.
Comparison with === (value and type)
Deep equality comparison, it means equal keys and values (useful with Objects)
undefined
is different than null
. Sometimes we need to check our methods or variables are defined.
Different to undefined
. We validate that the actual value to be exactly null
.
When looking for a subString of the value in your expect
expect
the value to be Not a Number. Careful to not write Nan instead of Nan.
e.g. to understand more about NaN:
20 + 'a' // '20a'
20 * 'a' // NaN
20 * '' // 0
NaN === NaN // false
Number.isNaN('') // false
Number.isNan(NaN) // true
Be careful to wrap the expected result inside a function to not break the expect before evaluation.
It can receive two parameters, expected and message
For regular expresions, remember to wrap de RegEx inside /RegEx/ or plain text for typeOf
It only doesn't work with null
and unedfined
You can create your own matcher. You have to create a file with the structure shown in custom-matchers.js. Then you define a compare function where you decide how it success and what message to show when it fails.
The matcher needs to be registered, so we need to import the file as a script in the html and import it in the suite
using structure jasmine.addMatchers(myMatcherName);
Note: If you compare {} == {}
you'll get false because they have different location in memory
That's why you need to use toEqual to match keys and values instead of its memory location.
'spec' is short for specification
We use describe
to group our specs, it's also called a suite.
We should nest the suites by methods
###Setup
Where you place prerequisites for your specs. It executes before specs are run:
beforeEach(): Executed before each spec (it
)
beforeAll(): Executed once before each suite (describe
) or before all the specs in which it is called.
###Teardown
Clean up steps for your specs. It executes after specs are run:
afterEach(): Executed after each spec (it
)
afterAll(): Executed once after each suite (describe
) or after all the specs in which it is called.
###xit To explicitly say the the spec is disabled, temporarily disabled or a pending spec. The spec won't be executed
Sometimes there are methods that are called in our test, but we are not testing them. Spies create test doubles and help us isolate dependencies for true unit testing! A test double is an object that can stand in for real object in a test, similar to a stunt in a movie.
A spy can stub any function and tracks calls to it and all arguments.
A spy only exists in the describe
and it
where they were defined.
Note: We can NOT spy on getters and setters in Jasmine.
toHaveBeenCalled: It only evaluates the methods was called, nothing else. toHaveBeenCalledWith toHaveBeenCalledTimes
Receives two parameters, the object that contains the method we are spying on and a string with the name of the method()
You rarely need to use this method, but in case you need it, it's going to call the real implementation.
You know the spy creates a double, so the real implementation is not happening there, sometimes you
could need the real implementation to happen, that's when you use and.callThrough()
Rare to use too. It allows to call a specific custom implementation when spying on a function. It recives a function as an argument, it should have the same signature like the one you're faking.
If you want an specific value to be return. Very similar to callFake() method but shorter
Useful when we want to test the getters and setters from a property.
It receives three arguments, the last one is optional and by default is a get
Useful to work with promises. For this you should use the done
callback in the describe, and call it
at the end of your spec. Also you should mock the request, since we are testing the async method, not the request.
In order to not include each file separately in out spec-runner.html npm will allow us to get the dependencies from lib folder in our proyect.
- Delete the lib folder
- Delete de spec-matchers.js file
- Install node if you don't have it already
- Create a package.json file using the command
npm init
in your directory (all default answers are ok) - Install karma with command
npm install karma --save-dev
- Install jasmine-core and karma-jasmine
npm i jasmine-core karma-jasmine --save-dev
- Install karma-jasmine-matchers
npm i karma-jasmine-matchers --save-dev
- Create karma.config.js and set it up, karma looks for it automatically.
This first part will cover the part of a basic karma configuration to run all your tests automatically without the need to register one by one.
We will need a headless browser, it is included in puppeteer package
9) Install puppeteer npm i puppeteer --save-dev
10) Add ChromeHeadless to karma config browsers array.
11) Install karma-chrome-launcher npm i karma-chrome-launcher --save-dev
to integrate to chrome headless browser
12) Add karma-chrome-launcher to your karma.conf plugins
13) Add process.env.CHROME_BIN = require('puppeteer').executablePath();
before module in karma config
Now the test are running in the console without the need to open a browser. What if want to see reports of the tests. Because we want to know how much % of our code is being tested:
- Install istanbul
npm i -D istanbul
. Making sure our lines are visited helping to generate the report - Install karma-cli
npm i -D karma-cli
. Needed for generate coverage reports. - Install karma-coverage
npm i -D karma-coverage
. Plugin - Add it to the plugins in karma configuration.
- Add a second reporter after dots, called
coverage
- Add a new key called coverageReporter to tell where the report is going to be saved
- Add preprocessors key to config istanbul library on the js files.
Now in the coverage>html folder, you have a index.html that you can open to see the full report.