Frontend Web Development with Angular CC BY-NC-ND Carrot & - - PowerPoint PPT Presentation

CC BY-NC-ND Carrot & Company GmbH

Frontend Web Development with Angular

CC BY-NC-ND Carrot & Company GmbH

Agenda

• Questions
• Some infos
• Testing of Frontend Applications
• Todos

CC BY-NC-ND Carrot & Company GmbH

Questions?

CC BY-NC-ND Carrot & Company GmbH

• Use constants and put them in a separate file if they might be used

elsewhere.

• Consistent coding style (see Angular Style Guide for naming conventions)
• Use Angular modules and structure your code

Some Infos

CC BY-NC-ND Carrot & Company GmbH

Testing

• f Frontend Applications

CC BY-NC-ND Carrot & Company GmbH

Today's Topics

• Motivation & Reasons
• Types of Tests
• Frameworks
• Jest

○ Matcher ○ Mocks & Spies ○ Snapshot testing ○ Test asynchronous code ○ Coverage Reports

• Angular Testing Utilities

○ Query DOM elements & trigger events ○ Shallow Component Tests

CC BY-NC-ND Carrot & Company GmbH

Today's Topics

• Cypress

○ Querying Elements ○ Interacting With Elements ○ Assertions ○ Core Concepts ○ Best Practices

• Configuration for Jest and Cypress
• Live Coding

○ Commands for starting the tests ○ Utility Functions ○ Write Unit & Integration Tests with Jest ○ Write E2E Tests with Cypress

CC BY-NC-ND Carrot & Company GmbH

Motivation

• You are implementing a new feature, feature 1.
• When it is implemented, it works, so you do not need any tests, right?!
• You deploy your application to production.
• You want to proceed, implement more features and deploy them.
• Suddenly feature 1 breaks, because you refactored a service that is used by

feature 1.

• At this point you regret that you (or even better, your teammate) did not write

any tests.

CC BY-NC-ND Carrot & Company GmbH

Reasons to write tests

• It saves time

○ Code refactoring is a “no go” because you can not see what parts of your application will fail ○ Had no time for writing tests? Your crappy implementation stays. ○ Developing becomes more fun as you are not being blocked by hard to find bugs.

CC BY-NC-ND Carrot & Company GmbH

Reasons to write tests

• Self-updating documentation

○ Some people like to read the comments ○ Some read the implementation itself ○ But some read the tests

• It is fun

○ People that write good tests, are also the best programmers ○ Your test is also a program ○ If you like programming, you should like writing tests

CC BY-NC-ND Carrot & Company GmbH

Reasons to write tests

• Preventing regression bug

○ When you find a bug ■ First write a (failing) test that reproduces the bug ■ Then fix the bug ■ This will never happen again

• Improve the implementation via new insights

○ Write tests and have trouble with it → maybe an indication that your implementation can be improved ○ Your tests let you think about input and output, corner cases and dependencies

CC BY-NC-ND Carrot & Company GmbH

Reasons to write tests

• 100% coverage feels good and makes you happy :)

CC BY-NC-ND Carrot & Company GmbH

Type of Tests

• Unit Tests
• Integration Tests
• End-2-End Tests (E2E)

There are more than 100 different tests, but these three are the major types of frontend testing. More types of tests: https://www.softwaretestinghelp.com/types-of-software-testing/

CC BY-NC-ND Carrot & Company GmbH

Unit Tests

• Test units in encapsulation
• Should have a very narrow and well defined scope
• Perfect for code that has no I/O or UI dependencies
• Keep modules independent of one another
• If there is a dependency, either mock the dependency or do integration tests
• Reasons to use functional programming and pure functions as much as

possible

○ The purer your application is, the easier you can test it

○ https://blog.mgechev.com/2017/11/12/faster-angular-applications-pure-pipes-memoization-pure-functions-part-2/

CC BY-NC-ND Carrot & Company GmbH

Integration Tests

• Tests that check the integration of two or more units

○ components, modules, classes, I/O, etc.

• Just check that the glue binding of some units works
• If the real I/O is difficult, slow, or flaky then in the integration tests test using a

fake/mock

○ Using a real DOM (using the browser) make the tests slow and flaky ■ → virtual DOM (VDOM)

CC BY-NC-ND Carrot & Company GmbH

• Test the whole application together, and test it as a user would
• Check that the glue binding of all units works
• Tests if all units are working together
• E2E tests tend to be flaky

○ Flaky tests are tests that usually pass, but sometimes fail ○ Reasons: ■ Different Timing ■ I/O (real browser, network, etc)

• Testing the main flows of your application not every detail

End-2-End Tests

CC BY-NC-ND Carrot & Company GmbH

Testing Pyramid

Unit Tests Integration Tests E2E Tests Number of Tests Flakiness Efficiency

CC BY-NC-ND Carrot & Company GmbH

Frameworks

• Karma

○ Test runner ○ Unit & integration tests ○ https://karma-runner.github.io/latest/index.html

• Jasmine

○ Framework to write tests (matcher, etc.) ○ Unit, integration & E2E tests ○ https://jasmine.github.io/

• Protractor

○ Framework to run and write E2E tests for angular applications ○ https://www.protractortest.org Are part and pre-configured within a new Angular project (ng new <project-name>)

CC BY-NC-ND Carrot & Company GmbH

Frameworks

• Jest

○ Framework to write and run tests ○ Unit & Integration tests ○ https://jestjs.io/

• Cypress

○ Framework to write and run E2E tests for any web application ○ https://www.cypress.io/ Our testing stack (already configured in your applications)

CC BY-NC-ND Carrot & Company GmbH

Why we do not use the default testing stack?

• Jest

○ Pro: ■ It’s fast ■ Uses jsdom (VDOM) (not slow, flaky browser) ■ Executes tests in parallel ■ Sits on top of Jasmine, so the API is nearly identical ■ Provides code coverage out of the box ■ Provides a smart, immersive watch mode

• Runs only tests affected by git file changes
• Also runs failed tests first
• Is able to stop on first error so the feedback loop is ~10x faster than with Karma

(depending on test suite size) ■ Provides snapshot testing ○ Con: ■ Uses jsdom (VDOM) (no real browser)

https://blog.nrwl.io/nrwl-nx-6-3-faster-testi ng-with-jest-20a8ddb5064

CC BY-NC-ND Carrot & Company GmbH

Why we do not use the default testing stack?

• Cypress

○ Pros: ■ No dependencies ■ Auto-reload ■ UI for debugging ■ Automatic waits

• No manual sleeps or waits
• Waiting for element to appear in the DOM

■ Clear and easy syntax ○ Cons: ■ Small Community ■ Lack of Features ■ Variety of browsers

https://blog.nrwl.io/nrwl-nx-7-0-better-e2e-testing-wi th-cypress-1b88336bef5e

CC BY-NC-ND Carrot & Company GmbH

Test Suite

Jest

Test Matcher Setup & Teardown

Matcher: https://jestjs.io/docs/en/using-matchers, https://jestjs.io/docs/en/expect Setup & Teardown: https://jestjs.io/docs/en/setup-teardown

CC BY-NC-ND Carrot & Company GmbH

Jest

• Mocks

○ Used in unit testing ○ Object under test may have dependencies on other objects. To isolate the behavior of the dependencies you can replace these dependencies by mocks. These mocks will simulate the behavior of the real objects. ○ Mocking is creating objects that simulate the behavior of real objects ○ const a = new A(new MockB(), new MockC()) ○ Mock functions in Jest with jest.fn(implementation) : https://jestjs.io/docs/en/mock-functions

CC BY-NC-ND Carrot & Company GmbH

Jest

• Spies

○ Keep track of the usage of a method of a class ○ jest.spyOn(object, methodName) ○ Creates a mock function similar to jest.fn but also tracks calls ○ By default, jest.spyOn also calls the spied method

https://jestjs.io/docs/en/jest-object#jestspyonobject-methodname

CC BY-NC-ND Carrot & Company GmbH

Jest

• Snapshot testing

○ Very useful tool whenever you want to make sure your UI or an object does not change unexpectedly ○ expect(object).toMatchSnapshot(); Angular Component:

https://jestjs.io/docs/en/snapshot-testing

my-test-component/ __snapshots__/my-test-component.component.spec.ts.snap

Important: Do not make snapshots of large component or

• bject because the snapshots could be hard to maintain!

CC BY-NC-ND Carrot & Company GmbH

Jest

• Testing Asynchronous Code

○ When you have asynchronous code, Jest needs to know when the code it is testing has completed, before it can move on to another test. ○ Use ■ Callback ■ Marble tests

CC BY-NC-ND Carrot & Company GmbH

Jest

Callback: Jest tests complete once they reach the end of their execution. That means this test will not work as intended!

https://jestjs.io/docs/en/asynchronous

CC BY-NC-ND Carrot & Company GmbH

Jest

rxjs-marbles: https://github.com/cartant/rxjs-marbles https://github.com/cartant/rxjs-marbles/tree/master/examples/jest hot vs cold observable: https://medium.com/@luukgruijs/understanding-hot-vs-cold-observables-62d04cf92e03

Marble Test:

CC BY-NC-ND Carrot & Company GmbH

Jest

Coverage Reports

• Jest will automatically generate a coverage report
• Just open the report in your browser:

○ Frontend/Web/reports/coverage/jest/lcov-report/index.html

• Coverage Threshold

○ If thresholds aren't met, Jest will fail (before commit git hook) ○ https://jestjs.io/docs/en/configuration.html#coveragethreshold-object

See: Frontend/Web/jest.config.js

CC BY-NC-ND Carrot & Company GmbH

The ComponentFixture properties and methods provide access to the component and its DOM representation.

Angular testing utilities

ng g component my-test-component TestBed: Easy way to create components, handle injection and interact with our

• application. It acts as a dummy Angular

Module. Compile the testing module Create a component Get the class of that component with all its properties and methods Trigger change detection

https://angular.io/guide/testing#testing-utility-apis

CC BY-NC-ND Carrot & Company GmbH

Angular testing utilities

Helper functions

https://github.com/brandonroberts/ng-atl-2018/blob/master/src/app/test-helpers.ts https://github.com/brandonroberts/ng-atl-2018/blob/master/src/app/test-providers.ts

CC BY-NC-ND Carrot & Company GmbH

Angular testing utilities

Helper functions

• Files:

○ Frontend/Web/src/app/testing-utils/create-component-test-fixture.ts ○ Frontend/Web/src/app/testing-utils/provide-mock.ts ○ Frontend/Web/src/app/testing-utils/trigger-event-helper.ts

CC BY-NC-ND Carrot & Company GmbH

Angular testing utilities

Shallow Component Tests

• Tells the Angular compiler to ignore unrecognized elements and attributes
• It simply renders them as empty tags
• No longer need the stub components
• Useful if you want to write a unit test for a component

https://angular.io/guide/testing#no_errors_schema

CC BY-NC-ND Carrot & Company GmbH

Angular testing utilities

Shallow Component Tests

https://angular.io/guide/testing#no_errors_schema

CC BY-NC-ND Carrot & Company GmbH

Angular testing utilities

Query DOM elements & trigger events

• DebugElement provides insights into the component's DOM representation

https://angular.io/guide/testing#debugelement-1

CC BY-NC-ND Carrot & Company GmbH

Cypress

https://docs.cypress.io/guides/getting-started/writing-your-first-test.html

CC BY-NC-ND Carrot & Company GmbH

Cypress

Querying Elements

• Querying for elements like in jQuery
• cy.get('.my-selector'), cy.get('#main-content')
• Querying by Text Content (what the user would see on the page)

○ cy.contains('New Post') ○ cy.get('.main').contains('New Post')

• Cypress will automatically wait for the element if not present

○ Gives your app a window of time to finish whatever it may be doing ○ timeout

https://docs.cypress.io/guides/core-concepts/introduction-to-cypress.html#Querying-Elements

CC BY-NC-ND Carrot & Company GmbH

Cypress

Interacting With Elements

• cy.get('textarea.post-body')

.type('This is an excellent post.')

• cy.get('button')

.click()

• cy.get(‘.my-checkbox’)

.check()

https://docs.cypress.io/guides/core-concepts/introduction-to-cypress.html#Interacting-With-Elements

CC BY-NC-ND Carrot & Company GmbH

Cypress

Assertions

• Cypress will automatically wait until your elements reach this state, or fail the

test if the assertions don’t pass

• cy.get(':checkbox').should('be.disabled')
• cy.get('form').should('have.class', 'form-horizontal')
• cy.get('input').should('not.have.value', 'US')

https://docs.cypress.io/guides/core-concepts/introduction-to-cypress.html#Asserting-About-Elements https://docs.cypress.io/guides/core-concepts/introduction-to-cypress.html#Assertions https://docs.cypress.io/guides/references/assertions.html

CC BY-NC-ND Carrot & Company GmbH

Cypress

Core Concepts

• Commands are asynchronous and relies on timeouts to know when to stop

waiting on an app to get into the expected state

• Commands get queued for execution at a later time
• During execution, subjects are yielded from one command to the next, and a

lot of helpful Cypress code runs between each command to ensure everything is in order

https://docs.cypress.io/guides/core-concepts/introduction-to-cypress.html#Cypress-Is-Simple

CC BY-NC-ND Carrot & Company GmbH

Cypress

Core Concepts

• Each Cypress command (and chain of commands) returns immediately,

having only been appended to a queue of commands to be executed at a later time

• You cannot do anything useful with the return value from a command
• Commands are enqueued and managed entirely behind the scenes

CC BY-NC-ND Carrot & Company GmbH

Cypress

Core Concepts

The commands are only getting queued, nothing will be executed! After the test function has finished execution, Cypress will begin running the commands in order.

CC BY-NC-ND Carrot & Company GmbH

Cypress

Best Practices

• Controlling State

○ X Using the UI to set your application into a given state ○ OK Programmatically set your application into a given state (REST calls, set localstorage, etc)

https://docs.cypress.io/guides/references/best-practices.html

CC BY-NC-ND Carrot & Company GmbH

Cypress

Best Practices

• Selecting Elements

○ X Using highly brittle selectors that are subject to change ○ OK Use data-* attributes to provide context to your selectors and insulate them from CSS or JS changes

CC BY-NC-ND Carrot & Company GmbH

Cypress

Best Practices

• X Having tests rely on the state of previous tests

CC BY-NC-ND Carrot & Company GmbH

Configuration for Jest and Cypress

Jest

• Files:

○ Frontend/Web/jest.config.js ○ Frontend/Web/src/jest-setup.ts ○ Frontend/Web/src/jest-global-mocks.ts

• https://jestjs.io/docs/en/configuration
• https://www.xfive.co/blog/testing-angular-faster-jest/
• https://izifortune.com/unit-testing-angular-applications-with-jest/

CC BY-NC-ND Carrot & Company GmbH

Configuration for Jest and Cypress

Cypress

• Files:

○ Frontend/Web/cypress.json ○ Frontend/Web/cypress/plugins/index.js ○ Frontend/Web/cypress/plugins/cy-ts-preprocessor.js

• https://docs.cypress.io/guides/references/configuration.html
• https://github.com/bahmutov/add-typescript-to-cypress

CC BY-NC-ND Carrot & Company GmbH

Live Coding

Sample Application https://gitlab.fwda.cnc.io/fwda/ng-modules

CC BY-NC-ND Carrot & Company GmbH

Live Coding

Commands for starting the tests

• Run Jest tests

○ With host machine ■ Make sure you have the node_modules installed

• ./cli/install_dev_frontend_web.sh

■ Execute the tests

• source ./conf/load_env.sh
• cd Frontend/Web
• npm run test
• Or
• ./cli/run_tests_frontend_web_unit.sh

CC BY-NC-ND Carrot & Company GmbH

Live Coding

Commands for starting the tests

• Run Jest tests

○ With docker ■ source ./conf/load_env.sh ■ docker-compose -f ./conf/docker-compose/docker-compose.base.yml

• f ./conf/docker-compose/docker-compose.dev.yml run --rm

frontend-web /bin/bash ■ npm run test

CC BY-NC-ND Carrot & Company GmbH

Live Coding

Commands for starting the tests

• Run Cypress tests

○ Does only work on your host machine, because the docker is not configured to run Cypress ○ Make sure you have the node_modules installed ■ ./cli/install_dev_frontend_web.sh ○ Your application must be running ■ ./cli/start_dev_docker.sh ○ Execute the tests ■ source ./conf/load_env.sh ■ cd Frontend/Web ■ npm run e2e.dev ■ npm run e2e (headless mode) ■ Or ■ ./cli/run_tests_frontend_web_e2e.sh [--headless]

CC BY-NC-ND Carrot & Company GmbH

It doesn’t really matter how you do your tests, as long as you write enough tests that make you feel confident that you can deploy your version to production.

CC BY-NC-ND Carrot & Company GmbH

Thank you for your attention!

Questions?

CC BY-NC-ND Carrot & Company GmbH

Sources

https://xebia.com/blog/5-reasons-why-you-should-test-your-code/ https://angular.io/guide/testing https://hackernoon.com/testing-your-frontend-code-part-i-introduction-7e307eac4446 https://medium.com/welldone-software/an-overview-of-javascript-testing-in-2018-f68950900bc3 https://www.xfive.co/blog/testing-angular-faster-jest/ https://codeburst.io/jest-the-next-generation-testing-8a6ee7c14656

Todos

• Complete 4th Sprint