Jest: Frontend Testing leicht gemacht @EnterJS2018
4 likes1,170 views
The document discusses Jest, a JavaScript testing framework developed by Facebook, emphasizing its ease of use, powerful features, and ability to streamline frontend testing for developers. It covers the fundamentals of setting up Jest, writing tests, utilizing mocking, snapshot testing, as well as the importance of code coverage. The speaker advocates for integrating testing early in the development process to enhance code quality and maintainability.
![Expectations: Examples
Expecting Objects
1 describe('createCustomer should’, () => {
2 it('produce a valid customer',() => {
3 const customer = {name: 'Peter', premium: true};
4 expect(customer).toBeDefined();
5 expect(customer.name).toEqual('Peter');
6 expect(customer.name).toEqual(expect.stringContaining('ete'));
7 expect(customer).toEqual(expect.objectContaining({premium: true}));
8 })
9 });
Expecting Arrays
describe('createCustomers should', () => {
it('work with many customer',() => {
const customers = [
{name: 'Peter', premium: true},
{name: 'Max', premium: false},
{name: 'Tine', premium: true}
];
expect(customers).toContainEqual({name: 'Tine', premium: true});
})
});
1
2
3
4
5
6
7
8
9
1
0](https://image.slidesharecdn.com/jesttalk-enterjs-180622081155/85/Jest-Frontend-Testing-leicht-gemacht-EnterJS2018-47-320.jpg)
![Snapshot tests
expect(validationMessage('Vorname')).toMatchSnapshot();
•Not (strictly) UI related!
•Jest stores result of function (i.e any serializable thing) to the fs the first run
•The stored thing is called Snapshot
exports[`validationMesssage should produce a valid message 1`] =
`"Feld 'Vorname' ist ein Pflichtfeld."`;
•Compares to this in consecutive test runs
expect(value).toMatchSnapshot()
Received value does not match stored snapshot 1.
- "Feld 'Vorname' ist ein Pflichtfeld."
+ "Das Feld 'Vorname' ist ein Pflichtfeld.“
› 1 snapshot test failed.](https://image.slidesharecdn.com/jesttalk-enterjs-180622081155/85/Jest-Frontend-Testing-leicht-gemacht-EnterJS2018-53-320.jpg)
![What we had to do
{
"presets": ["env"]
}
Install dependencies $ npm install -D jest
package.json
"scripts": {
"test": "jest",
"test:watch": "jest --watch"
}
babel
//.babelrc
{
"presets": ["env"]
}
$ npm install -D babel-jest babel-core
babel-preset-env](https://image.slidesharecdn.com/jesttalk-enterjs-180622081155/85/Jest-Frontend-Testing-leicht-gemacht-EnterJS2018-63-320.jpg)
Jest: Frontend Testing leicht gemacht @EnterJS2018
- 1. Holger Grosse-Plankermann Jest: Frontend Testing done right
- 2. Who am I? Developer/Consultant/Whatever Taming the Web since the 2000 Compiled Mozilla for bonus features Backend vs. Frontend dev Podcaster http://autoweird.fm Holger Grosse-Plankermann @holgergp http://github.com/holgergp
- 3. Show of hands Do you test your frontend code? •Unit Testing •Selenium/Test Cafe etc. •Integrated Tools (e.g. Katalon) •Macros 4
- 4. Show of hands What test framework are you using? •Jest •Mocha •Karma 5 •Jasmine •Qunit •Something else?
- 5. AGENDA What is Jest Why another library? (Unit-) Tests in JavaScript Where do I come from? Where are we heading? Top 3 reasons for Jest Why I think Jest is awesome!
- 6. 7 Where do I come from (Unit-) Testing JS
- 7. Test Pyramid E2E Test Unit Test Integration Test
- 8. Backend Test Pyramid E2E Test Unit Test Integration Test
- 9. Frontend Test Pyramid Unit Test E2E-Test Integration Test
- 10. •Backend (Java) testing is well established •The important stuff is in the backend! Some enterprise architect •Need for unit testing •And tooling is quite nice tbh •mvn clean install ftw In the backend
- 11. In the frontend •Frontend (JS) testing used to be an afterthought •Less (underrated!) complexity •Nah! We don’t need to test that The same enterprise architect •Messy tooling •Tons of config and dependencies needed to be orchestrated •And that rumor is still in our heads
- 12. •In the age of SPAs •More code than in the past •Complex code •Frontend code in itself is complex •Also: Compared to backends •Need for testing is already there •Selenium is not enough! Proper Testing in the frontend is important
- 13. Two sided test pyramid E2E Test Unit Test Integration Test Unit Test Integration Test Frontend Backend
- 14. 14 A library that puts the fun in testing Enter Jest
- 15. Delightful JavaScript Testing https://facebook.github.io/jest/ •Testing library/framework •Comparable to •JUnit (Java) •Test::Unit (Ruby) •PHPUnit (PHP) What is Jest?
- 16. •Developed by Facebook •Current version 23 •MIT licensed •> 18.000 Github Stars •Has been around since 2014 Jest: Facts and figures
- 17. •Comes from Facebook but it’s not limited to React •Works like a charm in my projects •React based •Vue based •JQuery backed Jest: Facts and figures
- 18. Easy Setup You can start with very little config Awesome CLI A really polished product All in the box Little to no need for third party libs Why I like Jest
- 19. 19 Simple to install and simple to use Easy setup
- 20. Create-React-App Probably the easiest way to get going is to just use create-react-app. repl.it Use an online repl might be even easier. npm install jest Come on, let’s get our hands dirty! Let’s get started I want to write the first test!
- 21. Be amazed Install dependencies $ npm install -D jest Let’s get started package.json "scripts": { "test": "jest", "test:watch": "jest --watch" } Write a simple test describe('Demo should', () => { it('be green', () => { expect(true).toBe(true); }); }); Run it $> npm test PASS ./demo.spec.js Demo should ✓ be green (2ms) Test Suites: 1 passed, 1 total Tests: 1 passed, 1 total Snapshots: 0 total Time: 1.606s Ran all test suites.
- 22. Anatomy of a test describe("add", () => { beforeEach(() => {}) afterEach(() => {}) beforeAll(() => {}) afterAll(() => {}) it("should compute the sum", () => { expect(add(1, 2)).toBe(3); }); }); test("should compute the sum", () => { expect(add(1, 2)).toBe(3); }) This gives a nice descriptive scoped structure of your test. As a bonus, Jest can print the results nicely, I can recommend that structure. A more traditional way of writing your tests. Possible, but less expressive than the describe style.
- 23. Best practice: Nested blocks •Use nesting of describe blocks to group your tests logically •Setup code can be fine tuned for specific case •Setup in nested describe describe('Customer', () => { beforeEach(() => {}); describe('placeOrder should', () => { beforeEach(() => {}); it('be valid', () => { expect(customer.placeOrder()).toBe(true); }); }); describe('checkQty should', () => { beforeEach(() => {}); it('be valid', () => { expect(customer.checkQty()).toBe(1); }); }); }); 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
- 24. Useful shortcuts fdescribe()/describe.only() fit()/it.only() ftest()/test.only() Executes only this block (in the block) Skips the block xdescribe()/describe.skip() xit()/it.skip() xtest()/test.skip()
- 25. Where are my tests? •Out of the box, Jest looks for __tests__/* bar.spec.js foo.test.js •Configurable •Suited my needs well thus far
- 26. Best practice: Code and Test nearby •Makes it way easier to navigate between code and test •Unusual at first, but grow fond of it add.js add.spec.js mockable.js mockable.spec.js objectProducer.js objectProducer.spec.js stringProducer.js stringProducer.spec.js src/myApp
- 27. There is more •Works with ES6 •With Babel •Compile to JS friendly •e.g. works (now) well with TypeScript •All presets are configurable •package.json •CLI •JS
- 28. Test runner trivia •Jest runs •tests in parallel •tests in a sandbox •No conflicting of tests •failed tests first
- 29. Runs in your CI Server I work with it in: •Travis •Gitlab CI •Jenkins
- 30. 28 Fun to work with Awesome CLI
- 31. PASS client/service/skippingAndForcing.spec.js PASS client/service/customMatchers.spec.js PASS client/service/asymetricExpectations.spec.js PASS client/service/serviceUser.spec.js PASS client/service/newExpectations.spec.js PASS client/service/httpServiceWithPromises.spec.js PASS client/components/FirstTest.spec.js PASS client/components/TextComponent.spec.jsx PASS client/components/App.spec.jsx (5.539s) PASS client/components/ListComponent.spec.jsx (5.589s) Test Suites: 10 passed, 10 total Tests: 5 skipped, 23 passed, 28 total Snapshots: 5 passed, 5 total Time: 9.83s Ran all test suites. Test results •Nice output out of the box
- 32. FAIL ./add.spec.js ● add › should compute the sum expect(received).toBe(expected) // Object.is equality Expected value to be: 4 Received: 3 8 | 9 | it('should compute the sum', () => { > 10 | expect(add(1, 2)).toBe(4); 11 | }); 12 | }); 13 | at Object.<anonymous> (add.spec.js:10:27) PASS ./asymetricExpectations.spec.js .. Test Suites: 1 failed, 8 passed, 9 total Tests: 1 failed, 5 skipped, 15 passed, 21 total Meaningful error reports
- 33. Watch mode •Looks for changes in the background •Executes test automatically •And more! •Start via: $ jest --watch
- 34. Watch mode Demo
- 35. Watch mode Demo
- 36. Watch mode Demo
- 37. Watch mode Demo
- 38. Watch mode Demo
- 39. Best practice: Watch mode on •You get very fast feedback •Nice for TDD •Immersive •One less task to do manually •Make it a habit
- 40. Code coverage $ jest --coverage PASS client/service/newExpectations.spec.js Ran all test suites. -----------------------------|----------|----------|----------|----------|----------------| File | % Stmts | % Branch | % Funcs | % Lines |Uncovered Lines | -----------------------------|----------|----------|----------|----------|----------------| All files | 90.91 | 100 | 86.67 | 93.33 | | components | 100 | 100 | 100 | 100 | | App.jsx | 100 | 100 | 100 | 100 | | ListComponent.jsx | 100 | 100 | 100 | 100 | | TextComponent.jsx | 100 | 100 | 100 | 100 | | service | 81.25 | 100 | 77.78 | 84.62 | | httpService.js | 100 | 100 | 100 | 100 | | httpServiceWithPromises.js | 100 | 100 | 100 | 100 | | serviceUser.js | 62.5 | 100 | 50 | 66.67 | 9,10 | -----------------------------|----------|----------|----------|----------|----------------| •Computes coverage out of the box
- 41. Best practice: Coverage is your friend •Sane default out of the box •I use it regularly to see, where some test love may be needed •Don’t go overboard with the numbers •Use it as a guideline •CI is a good place to make this visible
- 42. $ jest --verbose PASS client/components/App.spec.jsx App ✓ renders (14ms) ✓ calling Service correctly (3ms) PASS client/service/httpServiceWithPromises.spec.js httpService getPosts should ✓ talk to the backend using done (1ms) ✓ talk to the backend using promise returns ✓ talk to the backend using async await (1ms) httpService getPostsRejecting should ✓ reject using done ✓ reject using expectations ✓ reject using async await (1ms) Test Suites: 10 passed, 10 total Tests: 5 skipped, 23 passed, 28 total Snapshots: 5 passed, 5 total Time: 2.187s Ran all test suites. Even nicer output •verbose option
- 43. IDE Support It just works •I use it mainly in IntelliJ/Webstorm and it just works •Use a Run Config like any other test •Works fine in VSCode •Some more config •Not as polished as IntelliJ •But fine for me •I use the Jest extension •I often use it on the command line •Alongside the IDE •The watch feature shines there
- 44. 3 Less need for 3rd party libs Batteries included
- 45. Expectations Mocking Snapshot Tests What’s in the box Async Tests DOM Testing Code coverage
- 46. Expectations .toBe(value) .toHaveBeenCalled() .toBeCloseTo(number, numDigits) .toBeDefined() .toBeFalsy() .toBeGreaterThan(number) .toBeGreaterThanOrEqual(number) .toBeLessThan(number) .toBeLessThanOrEqual(number) .toBeInstanceOf(Class) .toBeNull() .toBeTruthy() .toBeUndefined() .toContain(item) .toContainEqual(item) .toEqual(value) .toHaveLength(number) .toMatch(regexpOrString) .toMatchObject(object) … •No need for separate Mocha/Jasmine/expect •All the expectations you need •Matchers are extendable https://facebook.github.io/jest/docs/en/expect.html
- 47. Expectations: Examples Expecting Objects 1 describe('createCustomer should’, () => { 2 it('produce a valid customer',() => { 3 const customer = {name: 'Peter', premium: true}; 4 expect(customer).toBeDefined(); 5 expect(customer.name).toEqual('Peter'); 6 expect(customer.name).toEqual(expect.stringContaining('ete')); 7 expect(customer).toEqual(expect.objectContaining({premium: true})); 8 }) 9 }); Expecting Arrays describe('createCustomers should', () => { it('work with many customer',() => { const customers = [ {name: 'Peter', premium: true}, {name: 'Max', premium: false}, {name: 'Tine', premium: true} ]; expect(customers).toContainEqual({name: 'Tine', premium: true}); }) }); 1 2 3 4 5 6 7 8 9 1 0
- 48. Best practice: Few expectations •Don’t go overboard with the expectations in the it blocks •In doubt write one more it block •Expectations following a failing expect don’t execute
- 49. Mocking In a unit test it is often unfeasible to kickstart your whole dependency graph Mocking lets you narrow down the scope of your test { }{ }
- 50. Mocking •No need for separate Sinon.js •Works similar to Mockito in Java Mock Functions Lets you replace more complex logic with logic right for your test Manual Mocks Lets you replace whole modules for your test
- 51. Mock functions describe('placeOrder should', () => it('order an available product', () => { const product = { isAvailable: jest.fn().mockReturnValue(true), order: jest.fn() }; placeOrder(product, 2, 'SOMMER'); expect(product.order).toHaveBeenCalled(); expect(product.order).toHaveBeenCalledTimes(1); expect(product.order).lastCalledWith(2); expect(product.order).toHaveBeenCalledWith(2); }) ); 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 export function placeOrder(product, qty, seasonId) { if (product.isAvailable(seasonId)) { product.order(qty); } } 1 2 3 4 5
- 52. Best practice: Mock to reduce scope •Use mocking if •you set things up that don’t belong to your test •you are only interested in the result (or an error!) of a dependency •This makes the test more readable and potentially faster •But beware if you see too much mocking involved •Maybe your test can be smaller •Maybe you need to restructure your dependencies
- 53. Snapshot tests expect(validationMessage('Vorname')).toMatchSnapshot(); •Not (strictly) UI related! •Jest stores result of function (i.e any serializable thing) to the fs the first run •The stored thing is called Snapshot exports[`validationMesssage should produce a valid message 1`] = `"Feld 'Vorname' ist ein Pflichtfeld."`; •Compares to this in consecutive test runs expect(value).toMatchSnapshot() Received value does not match stored snapshot 1. - "Feld 'Vorname' ist ein Pflichtfeld." + "Das Feld 'Vorname' ist ein Pflichtfeld.“ › 1 snapshot test failed.
- 54. Test that would require some effort to expect React components (that should not change) Things you would not test otherwise Best practice: Use Cases for snapshot tests
- 55. Snapshot test may be brittle You NEED to review your snapshot changes No jest -u fire and forget Prefer unit tests Best practice: Caveats of snapshot tests
- 56. it("talk to the backend using done", done => { getCustomers().then(data => { expect(data).toEqual(TEST_RESPONSE); done(); }); }); 1 2 3 4 5 6 Async tests •You’ll encounter async code quite frequently •Testing using callback way still works well •Known from Jasmine
- 57. Async tests it("talk to the backend using promise returns", () => { return getCustomers().then(data => { expect(data).toEqual(TEST_RESPONSE); }); }); 1 2 3 4 5 •Return a promise it("talk to the backend using expectations", () => { expect(getCustomers()).resolves.toEqual(TEST_RESPONSE); }); 1 2 3 •Use a matcher to resolve the provided promise it("talk to the backend using async await", async () => { const customers = await getCustomers(); expect(customers).toEqual(TEST_RESPONSE); }); 1 2 3 4 •Use async/await
- 58. DOM testing •Jest comes with JSDOM to support testing DOM. •JSDOM simulates a DOM-enviroment. it('show text on page', () => { const text = document.querySelector('#myText').innerHTML; expect(text).toEqual('Lorem'); }); 1 2 3 4 const setupDOM = () => { document.body.innerHTML = '<div>' + ' <div id="myText">Lorem</div>' + '</div>'; }; 1 2 3 4 5 6 •In a test you can setup a mock structure of your sites markup •Assert in the DOM •Useful when in conjunction with e.g. JQuery
- 59. Best practice: Keep away from DOM •As long as you can •Tests will be slow and brittle •If you must expect sth in the DOM, keep it brief
- 60. DOM testing (outlook) Test the rendering of your React application: Enzyme (http://airbnb.io/enzyme/) Enzyme is a JavaScript Testing utility for React that makes it easier to assert, manipulate, and traverse your React Components' output. Browser testing using Jest: Puppeteer (https://github.com/GoogleChrome/puppeteer) and its Jest integration (https://facebook.github.io/jest/docs/en/ puppeteer.html) Puppeteer is a Node library which provides a high-level API to control headless Chrome or Chromium over the DevTools Protocol.
- 61. Expectations Mocking Snapshot Tests What’s in the box Async Tests DOM Testing Code Coverage And more
- 62. 53 Some closing words Coming to an end
- 63. What we had to do { "presets": ["env"] } Install dependencies $ npm install -D jest package.json "scripts": { "test": "jest", "test:watch": "jest --watch" } babel //.babelrc { "presets": ["env"] } $ npm install -D babel-jest babel-core babel-preset-env
- 64. Easy to use and setup Powerful features set yet familiar Polished product (even the CLI) Try Jest yourself
- 65. facebook.github.io/jest/ Some links Tryout Jest Release Blog facebook.github.io/jest/blog/ Curated Links github.com/jest-community/awesome-jest Sample Code github.com/holgergp/jestStarter
- 68. Questions?
- 69. Our mission – to promote agile development, innovation and technology – extends through everything we do. codecentric AG Hochstraße 11 42697 Solingen E-Mail: [email protected] www.codecentric.de Telefon: +49 (0) 212. 23 36 28 0 Telefax: +49 (0) 212.23 36 28 79 Address Contact Info Telephone Stay connected Thanks for listening!