Learn Jest, Loopback and Mocha

In this collection, we build a minimal flashcard application using React, primarily focusing on function components and the hooks API. To make sure we can understand and maintain existing code, there are also a few lessons toward the end that use class components so you can get familiar with the syntax. We cover important React concepts, and sprinkle in libraries that are pretty standard in the ecosystem like @reach/router, Jest, and React testing library. We start with create-react-app so we can get right into it without worrying about configuring tooling. There's [a separate course for that here](https://egghead.io/courses/modern-javascript-tooling-with-react?af=5mx0ie)

jest

Build a React App with the Hooks API

In this course we are going to work through properly setting up Enzyme with Jest to test rendered components. This includes the nitty gritty of making our testing environment work with various versions of React. After we get our environment setup ready, we’ll work through the different ways we can render a component within our test pages. With a rendered component we can now test component methods and properties to assert that they are what is intended. 

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

Test React Components with Enzyme and Jest

End-to-end testing assures you of a few things: that all the integrated pieces of an application properly function, all those pieces work together as expected, and your tests include and simulate real-user scenarios — something unit and integration tests just don't do.

This course introduces you to two great tools for E2E testing: 

* Puppeteer opens and runs applications in a Chromium browser and performs the actions it's given.
* Jest asserts that the integrated pieces work as expected and that add-on libraries like Faker and pixelmatch take our tests to the next level.

Over 9 lessons, we will create common application features and use Puppeteer and Jest to run different types of tests against them. You'll get practice using these tools to render content, mimic user activity, automate tests, and measure the overall performance of your application.

End to End Testing with Google's Puppeteer and Jest

In this course the developer will learn how to create a LoopBack API and build it out to an API that can be used as a backend for apps. We will start by creating a basic LoopBack API project and gradually enhance it to a production ready API. The API we create defines a few models to persist the data and has custom functionality, validation and hooks added to those models. 

After our data structure is defined we will learn how to extend the functionality of LoopBack by using mixins and components. We will also lock our API down using ACL’s and create a mechanism to automatically define the admin and user roles and create our admin user.   

The last part of the course will show how how to filter the data stored in the API. We will make the API production-ready by adding unit tests, connecting it to MongoDB and we will show how to deploy the app to now.sh.   

LoopBack is a highly-extensible, open-source Node.js framework.

loopback

Build a Node.js REST API with LoopBack

Here are all the Egghead.io lessons about testing with Jest! http://facebook.github.io/jest (https://kcd.im/egghead-jest)

Testing JavaScript with Jest

Kent walks us through the internals of dom-testing-library and react-testing-library. 

There is a lot of set-up and tear down when testing UI components. These two libraries take away a lot of the work required to test React components well. 

Jest is commonly used in tandem with react-testing-library to assert results of your components. Jest simulates most browser apis with jsdom. react-testing-library helps you get values out of your components the same way your end users will. 

Links from the show:
- [Testing Library](https://testing-library.com)
- [Testing Javascript](https://testingjavascript.com)
- [Unit vs Integration vs E2E](https://kentcdodds.com/blog/unit-vs-integration-vs-e2e-tests)
- [Why you shouldn't ReactDOM.render to the body](https://medium.com/@dan_abramov/two-weird-tricks-that-fix-react-7cf9bbdef375)
- [Effective Snapshot Testing]( https://kentcdodds.com/blog/effective-snapshot-testing/)
- [Dev Tips with Kent](https://youtu.be/ttmvAm6esSc)
- https://kcd.im/news

Understanding how react-testing-library works with Kent C. Dodds

JavaScript® (often shortened to JS) is a lightweight, interpreted, object-oriented language with first-class functions, most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic, and supports object-oriented, imperative, and functional programming styles.

javascript

To be useful and trustworthy, your CLIs should be extraordinarily reliable. Investing in testing early will reap rewards in future. We show how to set up basic tests with Jest and Oclif's test helpers.

Test Node.js CLIs with Jest and Oclif

Components do more than just render an initial view based on props. Components may also maintain their own internal state and update that state in response to events. Those state changes, will then lead to updates to the rendered output. In this lesson, we'll cover how to test a component and verify that it behaves as expected when we simulate a click event.

Test Component Interactions with Jest and Testing Library

As the core unit of functionality in a React application, our components should be tested. Using Jest and Testing Library, we can render our individual components right in a test context and make assertions about their rendered output and behavior. Tests are a great way to work through API decisions, provide living documentation for your code, and to allow for confidence when refactoring. In this lesson, we'll create an initial test to verify the initial rendered output for a component, given specific props.

Test Component Rendering with Jest and Testing Library

Our unit tests should never rely on code that is outside our control and they certainly shouldn't be calling across the network to a server. A good test needs to be repeatable and fast and relying on outside systems and/or data doesn't help us meet those goals. In this lesson, we'll use mocks to create an environment where we control the response for service calls. This will allow us to be confident in our assertions and ensure our tests aren't flaky.

Mock Modules in a React Component Test

Any time your test interacts with a React component in a way that results in a state update, you need to make sure you wrap that interaction in an `act` function call, otherwise you'll get the "not wrapped in act(...)" warning.

In this lesson you'll learn how you can use `act` with `@testing-library/react-hooks` to avoid potential bugs in your custom React hooks.

This is based on my blog post: [Fix the "not wrapped in act(...)" warning](https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning)

Fix the "not wrapped in act(...)" warning when testing Custom Hooks

The dreaded `act(...)` warning is really annoying, but actually really important. I've yet to see it be wrong (even when I thought it must be!). Every time it's pointing out something that is important that I'm missing in my test. In this lesson we'll identify a missing piece to our test and use act to make sure we avoid that in the future.

This is based on my blog post: [Fix the "not wrapped in act(...)" warning](https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning)

Fix the "not wrapped in act(...)" warning

There aren't many places you need to manually use `act` if you're using [React Testing Library's async utilities](https://testing-library.com/docs/dom-testing-library/api-async), but if you're using fake timers, you need to manually use `act` to avoid missing bugs in your code.

In this lesson you'll learn how to identify the cause of `act` warnings and how to resolve them.

This is based on my blog post: [Fix the "not wrapped in act(...)" warning](https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning)

Fix the "not wrapped in act(...)" warning with Jest fake timers

Use cases for `useImperativeHandle` are few and far between, but if you're testing a component that uses this React hook, you need to wrap any function you expose which results in state updates when called in React's `act` utility. Otherwise you could be missing important things in your tests that could result in bugs shipped to production.

In this lesson we'll learn how to identify what needs to be wrapped in `act(...)` and how to wrap those interactions.

This is based on my blog post: [Fix the "not wrapped in act(...)" warning](https://kentcdodds.com/blog/fix-the-not-wrapped-in-act-warning)

Fix the "not wrapped in act(...)" warning when testing the useImperativeHandle Hook

If you're not careful you can write a test that's worse than having not tests at all. In this lesson we'll learn why that is and how you can avoid it by making sure your test can fail.

This is based on my blog post: [Make Your Test Fail](https://kentcdodds.com/blog/make-your-test-fail)

Make Your Test Fail

One of the strengths of [Nx](https://nx.dev) is that it provides you easy access to some of the best tooling available. As such, whenever you generate a new app or lib inside an Nx workspace, it automatically preconfigures Jest for you and even sets up some pre-generated tests.

Run Jest tests for a React app with Nx

A relation in LoopBack is a way to associate the data from multiple models with each other. LoopBack supports various types of relations each with a different use case.

In this lesson we will create a second model called Category and create a relation between the Category and the Product models. To do this we will first add a property to the Product model called `categoryId`. This will allow us to store for each Product the category it belongs to. We then move on to create the actual relationships. 

Our first relationship defines that a `Category hasMany Products` and the second one that a `Product belongsTo a Category`.

After defining these relations we will use the API Explorer to see how we can interact with this related data.

Create a relation between two LoopBack models

In this lesson we will look at the filters that can be used to retrieve and manipulate the data stored in LoopBack. 

We will use [Postman](https://www.getpostman.com/) to interact with the `/Categories` and `/Products` endpoints. 

Using the URL parameters we will apply at the various filters LoopBack has to offer: `include`, `order`, `where`, `fields`, `limit` and `offset`. 

Filter model data in LoopBack

In this lesson we look at extending the functionality of LoopBack models by defining a remote method. 

A remote method is a method on a model exposed over a custom REST endpoint. 

Using the `lb remote-method` command we will create the remote method meta-data in `product.json`. We will verify that this got created and that we see the new REST endpoint got added. Then we will create the actual method in `product.js` and enhance it so that the API will return an error if we want to buy a negative amount of products.

Define a remote method on a LoopBack model

In this lesson we will create a dynamic datasource in LoopBack. If the API is started with the environment variable `MONGODB_URL` it will use this url and the `loopback-connector-mongodb` package to store the data in MongoDB.

In the course we will use a local MongoDB instance. If you don't have MongoDB running locally you can always create a [free MongoDB Atlas database](https://egghead.io/lessons/create-a-free-database-on-mongodb-atlas).


Create a MongoDB DataSource in LoopBack

In this lesson you will learn how to persist the data from the memory connector. As the name suggests, the memory connector stores the data in memory. This means that if you restart the server, the data is gone. In development mode it can be useful to store this data in a file, so it gets persisted between server restarts, and it can be easily inspected.

Topics

Instructors

Content Type