DEV Community: Jake Dowie

Password Security in 2022 - What you need to know

Jake Dowie — Fri, 24 Sep 2021 13:57:49 +0000

92% of UK businesses experienced a cyberattack in the last 12 months

(Keeper 2021 UK Cybersecurity Census)

In this age of hacking and cyber-terrorism, your company's data is a target. And it doesn't take much for a hacker to break into a network and wreak havoc. The stakes are high. What do you need to know about password security?

This blog post will cover (almost) everything that those with responsibility for IT should know about passwords - from the basics to the latest trends in protection. We'll give you all the information necessary so that you can make informed decisions when it comes to protecting your company's assets from hackers and other threats.

While this guide is aimed at those responsible for an organisation’s IT security it’ll hopefully be useful to anyone interested in password security or those just trying to understand why so much emphasis is put on their company’s IT security policy.

23,000,000 account-holders in the UK use the password “123456”

(Nord Pass, 2020)

Why password security is important

65% of UK businesses relaxed their cybersecurity polices during the pandemic

(Keeper 2021 UK Cybersecurity Census)

Hopefully this will be pretty obvious so I won’t go on about it, but it can’t hurt to briefly run through it again…

Passwords have been with us for a very long time and will likely be with us for quite a while longer. Despite their obvious flaws, they’re still ubiquitous.

Passwords and usernames/email addresses (credentials) are often the first line of defence between your organisation’s sensitive data and the army of cyber-criminals trying to access it.

Gaining access to precious corporate data using credentials found via social engineering (mechanisms such as phishing and smishing) is still the most common cause of data breaches.

The risks to your organisation of a data breach are not only related to the sensitivity of your data were it to get into the wrong hands. With the rise of ransomware, you also need to consider the implications of losing access to your own data.

Weak passwords and poor password security can effectively leave the door open to cyber-criminals so if IT security is your responsibility you can’t really afford to ignore it! It’s also one of the simplest things to fix in the often highly complex world of IT security.

It takes less than a second to crack 8 of the top 10 most used passwords

(Nord Pass, 2020)

How to improve password security

29% of adults worldwide rotate between 5 and 10 different passwords

(Proofpoint, 2020)

There are lots of ways to increase the password security of your organisation. Some of them require quite a bit of technical knowledge to implement but there are also some pretty simple ones too. Most of them are relatively cheap to implement, at least compared to the potential cost of a security breach!

What does a strong password look like?

A relatively fundamental thing is to first understand what makes a good password.

A strong password follows a couple of simple rules. It should:

Be of a sensible minimum length
Contain a mix of lowercase and uppercase letters, numbers and symbols

A password of 15 numbers can be cracked in around 6 hours.

(howsecureismypassword.net)

A minimum of 16 characters is usually recommended for a secure password which should take at least 2 days to crack in a brute-force attack. If it contains a mix of upper and lower-case letters, numbers and symbols it’ll take up to 1 trillion years!

Ideally the restrictions placed on a password should be flexible enough to accommodate different types of passwords. For example, some people may find a password made up of a few random words easier to remember than a much shorter string of random characters. If a password is of significant length, the use of special characters becomes less relevant. An 18-character password of just lower-case letters will take around 23 million years to crack!

All of this may not seem relevant if you are going to implement a password manager but remember each user will still need a secure master password.

Data from https://howsecureismypassword.net/

“password” is the 4th most common password used

(Nord Pass 2020)

Password managers

16% of adults worldwide use the same one or two passwords for all accounts

(Proofpoint, 2020)

In case you’re not aware, password managers are SaaS products that manage the ever-increasing list of credentials most of us use in our working (and personal) lives.

When it comes to password managers, something is better than nothing. A basic password manager will mean that you don’t have to remember your credentials and in-built password generators can easily generate new secure passwords when required.

These days they will also often tell you if your credentials have been leaked in a security breach and prompt you to change the related password.

There are plenty of password management options out there, but they generally fall into two categories:

In-browser password managers

Although browser-based password managers are improving, they generally don’t have a lot of the really useful features of many 3rd party products.

They often have significant disadvantages over 3rd party products such as the fact that they lock you in to a particular browser. If you regularly switch browsers, for example if you use Chrome on Windows and Safari on your iPhone this kind of solution probably won’t work for you.

There are other features that you usually miss out on when using a browser-based password manager which are covered in the next section:

3rd party password managers

Cross platform and browser

If you're going to use a password manager you really want one you can use across all your devices. It's a pain finding you've generated a highly secure, reandom password, saved it to your password manager but can't access it on your phone!

Ability to share passwords

Despite it generally being bad practice, it may be necessary to have some passwords which are shared. For instance passwords for emergency accounts. Password managers often come with the ability to share credentials between accounts, often without even revealing the password to the person you're sharing it with, maintaining security.

Auditable

Many of these platforms allow managers to audit their team's use of the software, seeing if they're reusing passwords, have insecure passwords, or even if they're not using the software at all!

Enforcement policies/rules

Many rules can be specified which maintain a level of security. For example, prohibiting exporting data, or the reuse of master passwords, or requiring a unique master password.

Share credentials across sites

Credentials that are used across multiple sites can have their credentials easily shared without creating duplicates.

Add notes

It may be useful to be able to add notes to accounts, for instance if an account requires a password which needs to be quoted over the phone.

One-click change of credentials

Some password managers allow the credentials for specific sites to be changed with a single click.

NOTE: It’s worth mentioning that a password manager is only as secure as the master password used to access it. So, it’s really important that if your organisation uses a password management solution you set out some clear rules around master passwords, or even better, setup rules to enforce those policies.

These should include policies like:

No re-use of master passwords
Master passwords shouldn’t be written down
Master passwords should have minimum complexity rules making them more difficult to crack
MFA should be mandatory on password management tools

In a recent Microsoft Twitter poll, one in five people reported they would rather accidentally “reply all”—which can be monumentally embarrassing—than reset a password.

Multi-factor authentication (MFA)

20% of remote workers in the UK use their work email and password to log into consumer websites and apps

(Proofpoint, 2020)

This is the second most important step in securing your users’ logins and is usually pretty simple to implement. It’s also sometimes referred to as two-factor authentication (2FA).

The way this works is by requiring at least two authentication mechanisms (factors) before granting access to a resource. This means the user must be in possession of not just the relevant credentials, but also another piece of information which is not easily accessed.

Username/password credentials are usually the first factor and the 2nd factor can be one of a few things. The most common 2nd factors are:

An SMS message with a unique code
An email with a unique code
A unique code generated by an app (usually on a mobile phone)
A USB or NFC hardware device the user has access to
Biometric verification from a mobile device (e.g. facial recognition or a fingerprint scanner)

A lot of security-conscious software will have MFA built-in these days. In some cases it’ll just be a matter of turning on this feature. However, it’s becoming more common to have this feature turned on by default, or even mandatory given how much additional protection it can give.

MFA setup can be more complicated depending upon the types of factor supported. Some users can also find It a bit of a pain as it can require registering a separate device and can often increase the time it takes to login to a system. However, given the significantly increased level of security and peace of mind MFA can give to those with responsibility for an organisation’s security it’s often worth the trouble.

Single sign-on

88% of consumers across the world use the same password for more than one account

(Auth0, 2021)

Single sign-on (SSO) enables your users to use a single password to access multiple accounts.

The primary benefit of SSO to your users is that the number of credentials they need is reduced. There are also multiple benefits to your organisation of this approach.

The idea is that you allow a single provider to manage the login for multiple systems. For example, if you use Microsoft Active Directory (AD), you can use this solution to grant your users access to other corporate resources. These can be any corporate resources that support SSO, such as Google, Apple, Salesforce, Zoom and plenty of others.

This takes a bit of setting up but once you get the hang of it it’s not too difficult, and importantly it saves your users hassle and increases security.

An additional benefit of SSO is that if your user forgets their password, or leaves, IT have a single place to reset the password or disable the user account.

Having a single mechanism of authentication for multiple systems also makes user onboarding and offboarding significantly simpler for obvious reasons.

Passwordless authentication

“123456” is the most common password in use

(Nord Pass 2020)

The death of the password has been predicted from as far back as 2004 by Bill Gates, and it’s been predicted many times by many others since then.

However, it’s not until relatively recently that major authentication providers have embraced passwordless technologies.

Passwordless login is similar to MFA in the sense that it uses multiple factors to authenticate a user. The key difference is that it doesn’t require a password. It usually uses public-key cryptography to identify and authenticate a user. Basically, this means that the user provides their public identifier (email address, phone number, or username) and at least one other factor (containing their private key) to identify and authenticate them.

Significantly, in March 2021 Microsoft made passwordless sign-in generally available to commercial users. They have since (September 2021) made passwordless sign-in generally available to all users.

This may well signal the beginning of the end of the road for passwords, we’ll have to wait and see! Either way, passwords will certainly be with us for a while longer.

64% of UK organisations that have experienced a cyberattack in the last 12 months have between 1 and 100 employees

(Keeper 2021 UK Cybersecurity Census)

React component testing with Jest and React Testing Library

Jake Dowie — Tue, 07 Sep 2021 11:07:13 +0000

Testing React components gives you confidence a component will work when the user interacts with it. As a junior full-stack developer on my first job, I found it extremely useful in helping me understand our current codebase as well as allowing me to add value while learning.

This article is a summary of the information I found useful during my research and the answer to some challenges I came across. I don't hope to re-invent the wheel but to help others in a similar stage of their career. It's also assumed that you have some experience in writing tests.

Why Jest and RTL (React Testing Library)?

React openly recommends Jest as a test runner (perhaps because they maintain it) and RTL as their testing utility of choice. Jest testing is very fast, it's easy to set up and it has many powerful features such as mock functions which allow you to replace a specific function and return a desirable value or to check how the test subject is executing the function. RTL is very simple to set up, easy to make queries (including asynchronously) and because of how it was built, it'll help you write good tests.

Jest-Dom is not required but makes writing tests much easier because it extends Jest matchers (methods that let you test values in different ways e.g. toBe(), toHaveBeenCalled()) and allows you to write clearer tests.

Another popular tool is Enzyme, but many believe that it can lead to bad testing practices. The main concern is that Enzyme offers extra utilities that allow you to test the internal workings of a component (e.g. read and set state of the component). The team at React tests React; therefore, there is no need for you to test React’s functionality such as state, componentDidMount, etc. The same goes for other libraries you may use.

What to test?

When component testing in React, the focus should be on replicating how the user would interact with the React component. This means that we should test for what the user should or should not see, and how they are meant to interact with the app once it renders (e.g. that the value of a search/input field can be changed) instead of testing implementation (e.g. was componentDidMount called x number of times).

Some good questions to ask yourself when writing tests are:

What does the component render? Also, does it render differently under different conditions?
- This is what the user will see and potentially interact with. By thinking about it, you will also realise that users should access and see different information depending on certain conditions being met
What happens when the user interacts with the component?
- These are the parts of the app which the user will click, write into, etc. and they’ll expect something to happen. Tests should be written to prove that whatever is meant to happen does so when the event is triggered!
When a function is passed in as a prop, how does the component use it?
- You may need to recreate the behaviour of this function by using the Jest mock concept to know if the function has been called and the correct values were used

How to write a test?

So, onto the interesting part, how to test React components with Jest...

RTL’s most used functions are:

render – which renders the component
cleanup – which unmounts the React DOM tree that was mounted with render, and
fireEvent – to fire events like a click.

Jest's most used functions are:

expect along with a matcher
jest.fn() to mock a function directly
jest.spyOn() to mock an object method, and
jest.mock() for an entire module.

The test should be structured as follows:

Declare all jest.fn()/spyOn()/mock() with or without mocked implementations
Call RTL’s render function with the test subject as an argument – provide context whenever the component consumes a context. Also, if React-Router Link is used in this component, an object with a property wrapper and value MemoryRouter (imported from React-Router) must be passed as the second argument. Optionally wrap the component in MemoryRouter tags
Query the React DOM tree by using RTL’s query functions (e.g. getByRole() ) and check the values by call
Check values queried by calling expect() along with the relevant matcher. To replicate user interaction use fireEvent

RTL also returns a debug() method when render is called. Debug is fantastic for checking what is rendered in the React tree for situations like debugging your tests.

We will use the code below (a search field) as our example of a React component:

render = () => {
  const {
    validateSelection,
    minCharacters,
    placeholder,
    inputFluid,
    inputLabel,
    clear
  }: any = this.props

  const { isLoading, value, results } = this.state

  const icon = validateSelection ? (
    <Icon name="check" color="green" />
  ) : (
    <Icon name="search" />
  )

  return (
    <Search
      minCharacters={minCharacters}
      loading={isLoading}
      icon={icon}
      onResultSelect={this.onResultSelect}
      onSearchChange={this.onSearchChange}
      results={results}
      value={clear ? null : value}
      fluid
      placeholder={placeholder}
      input={{ fluid: inputFluid, label: inputLabel }}
    />
  )
}

Above we are destructuring props and state. We are also returning a Semantic UI React Search module. In essence, the above will render an input field. When changed, it will call onSearchChange and Semantic UI React will automatically pass two arguments, event and data (all props, including current value). One of onSearchChange’s jobs is to call an API and return results that match the current value.

Below are the tests we built for this component.

import '@testing-library/jest-dom/extend-expect'
import React from 'react'
import { render, cleanup, fireEvent } from '@testing-library/react'
import SearchField from './SearchField'

afterEach(cleanup)
jest.useFakeTimers()

test('<SearchField />', () => {
  const handleResultSelectMock = jest.fn()
  const apiServiceMock = jest
    .fn()
    .mockImplementation(() =>
      Promise.resolve({ entity: { success: true, data: ['hello', 'adios'] } })
    )

  const { getByRole, debug } = render(
    <SearchField
      handleResultSelect={handleResultSelectMock}
      apiService={apiServiceMock}
    />
  )

  const input = getByRole('textbox')
  expect(apiServiceMock).not.toHaveBeenCalled()
  expect(input).toHaveValue('')

  fireEvent.change(input, { target: { value: 'search' } })
  expect(input).toHaveValue('search')
  jest.advanceTimersByTime(600)

  expect(apiServiceMock).toHaveBeenCalledWith('search')
  expect(apiServiceMock).toHaveBeenCalledTimes(1)
  debug()
})

What is happening in the example above?

We imported all dependencies needed to test this component.

Jest DOM - to extend jest matchers
render, cleanup, fireEvent - React Testing Library utilities
SearchField - the React component being tested

import '@testing-library/jest-dom/extend-expect'
import React from 'react'
import { render, cleanup, fireEvent } from '@testing-library/react'
import SearchField from './SearchField'

We called Jest's function afterEach and passed RTL's method cleanup as an argument. cleanup will make sure that there are no memory leaks between tests by unmounting everything mounted by RTL's render method. We also called Jest's useFakeTimers function to mock timer functions.

afterEach(cleanup)
jest.useFakeTimers()

The component requires two props which should be functions. Therefore, we started by mocking two functions that will be passed to the component as props - handleResultSelectMock and apiServiceMock. handleResultSelectMock will be passed to handleResultSelect and apiServiceMock to apiService. Then, RTL's render method is called with the SearchField component as the argument.

test('<SearchField />', () => {
  const handleResultSelectMock = jest.fn()
  const apiServiceMock = jest
    .fn()
    .mockImplementation(() =>
      Promise.resolve({ entity: { success: true, data: ['hello', 'adios'] } })
    )

  const { getByRole, debug } = render(
    <SearchField
      handleResultSelect={handleResultSelectMock}
      apiService={apiServiceMock}
    />
  )
})

There will be times when the component being tested will require a `wrapper: Memory Router` or a `context` to render successfully. Take a look at the example below:

const { getByTestId, container } = render(
  <UserContext.Provider value={context}>
    <MainLoggedIn
      config={{
        get: jest.fn().mockImplementation(() => ({
          globalMenu: [{ requiredPermissions: ['Navbar'] }]
        }))
      }}
      history={{ history: ['first_history', 'second_history'] }}
      children={['first_child', 'second_child']}
    />
  </UserContext.Provider>,
  { wrapper: MemoryRouter }
)

After render is called, we should query the React DOM tree and find the elements we want to test. Below we used getByRole, but RTL offers many other query selectors functions.

const input = getByRole('textbox')

To check values, start with the function expect along one of the several matchers. Here we started by checking that the apiServiceMock has not been called, then checks that the input field is an empty string (value = '') when the component first renders.

expect(apiServiceMock).not.toHaveBeenCalled()
expect(input).toHaveValue('')

An event is fired using the function change of RTL's fireEvent to replicate the user's behaviour. This event will update the value of the input field from '' to 'search'. You can replicate other scenarios by using other fireEvent methods such as click(), mouseOver(). Jest's advanceTimersByTime method is called to move the mock timer forward by 600ms hence the number 600 is passed as an argument. advanceTimersByTime makes sure that tasks that have been queued by a timer function and would be executed within the given time (600ms in this case) will be executed.

fireEvent.change(input, { target: { value: 'search' } })
expect(input).toHaveValue('search')
jest.advanceTimersByTime(600)

After firing the event, we expect a few things to happen, the apiServiceMock function to be called once, and the argument passed to apiServiceMock to match the current input's value.

expect(apiServiceMock).toHaveBeenCalledWith('search')
expect(apiServiceMock).toHaveBeenCalledTimes(1)
debug()

Lastly, the debug function is called to check what is rendered in the React tree and help debug the tests.

Summary

Small and straightforward tests are better.
Test each component independently.
Focus on testing what the user will see and how they will interact with the component.
Start building the tests after assessing what needs to be tested.

GraphQL microservices - Combining data from multiple microservices

Jake Dowie — Thu, 17 Jun 2021 08:36:58 +0000

Introduction

Note: this post assumes a certain amount of familiarity with both microservice architectural style and GraphQL APIs. If you’re not familiar with either, check this in-depth tutorial on GraphQL and/or this primer on microservices.

Microservice-based application architectures have been increasing in popularity since their inception. Mostly because they’re widely held to solve several problems with monolithic application architectures: they’re more scalable, more reliable and easier to maintain.

It’s a similar story for GraphQL as an API architecture: since it went open source in 2015 it’s become extremely popular in application development because it improves on REST in several key ways: it solves under- and over-fetching problems, makes your APIs self-documenting, and again is easier to maintain.

At JDLT we’ve fully embraced both GraphQL and microservices for all these reasons and more, and as such we’ve learned a lot about how the two interact with each other, what challenges are posed by combining them, and how they bring out the best in each other. That’s what I’m going to talk about in this post.

The benefits and the conflict

One of the benefits of GraphQL is that it allows you to serve your whole API from a single endpoint. Rather than dozens of endpoints, each doing something different and defined by a unique path, your client applications and users can hit a single endpoint with a query that defines exactly what they want from it. This means you don’t have to worry about different developers using different naming conventions for paths and you don’t have to worry about having to make multiple requests just to get one data set. It also significantly simplifies API management.

Let’s say we have a social media app. Our app has a RESTful API with a /users/<id> endpoint. You might hit it and get back a user object, complete with a name and the id of our chosen user’s best friend. If we want to show the logged-in user their best friend’ names in our UI, then one option is to make two requests to /users/<id>; the first with the logged-in user’s id, and the second with her best friend’s id (which we only know from the response to the first call). This is slow (HTTP requests are probably the slowest part of your application) and it involves more code than we want to write. We want to write code to fetch some data we want, not code to fetch part of the data we want, and then once that’s come back to make another request which uses some of the first lots of data to fetch the rest.

Our other option is to define our API endpoints based on the UI view which they’ll provide the data for, i.e. to build an endpoint that returns not only a user’s data but also some data about that user’s best friend. The problem here is that now our ability to change our UI is linked directly to our ability to change our API — even if we now just want to show our user’s best friend’s profile picture to this view, we have to update our API to return it from the relevant endpoint. This might not slow the application down, but it certainly slows development down.

With GraphQL, our API knows how to retrieve a user for a given id, and it also knows that users have names and bestFriends. It even knows that bestFriends are in fact users and therefore it can retrieve a name (or even a bestFriend!) for the bestFriend of a given user. When our UI changes, we update our query to ask for the relevant data, but the API remains unchanged.

So, we’re sold on the benefits of a single API endpoint from which we can request whatever data we want. But, on the face of it, this seems to conflict with the fundamental concept of microservices: if they’re self-contained individual services, they define their own APIs; but if they all define their own APIs then we can’t access all of our data from a single endpoint.

And we really do want our microservices to be self-contained. Perhaps checking the name of a user’s best friend is the most popular feature of our application. In that case, our users service, which contains all the code to retrieve that information, will get used more than, for example, our email service, which might send notifications to our users when it’s their best friend’s birthday. So we probably want more instances of our users service running than of our email service, so that nobody gets any dropped requests for their best friend’s name, and we’re not paying for unneeded availability for our email service. But if the two are part of the same monolithic application (allowing one API to access them both), this seems to be impossible.

The solution

The solution to this problem is schema stitching, or, more specifically, GraphQL remote schema stitching. GraphQL schema stitching involves taking two separate GraphQL schemas (the data representation of a GraphQL API) and combining them into one. This is handy even in a monolithic application because it allows us to have two different services define their APIs in their respective directories, then stitch them together and expose them as a single API, essentially combining data from multiple microservices.

GraphQL remote schema stitching is the same, except the schemas we’re stitching together aren’t just coming from different directories on the same server, they’re coming from different servers (in our case, different microservices).

Once we know how to do that, we can create a new microservice that exists purely to stitch together the schemas from all our other microservices and expose them to create one GraphQL endpoint which can call any of our microservices. Essentially we'll be using a GraphQL microservice to allow combining data from multiple microservices.

Now we have a single GraphQL endpoint for our whole application, and our microservices are still totally self-contained.

The implementation

To implement this, we use a couple of npm packages from Apollo called graphql-tools and apollo-link-http. We'll also need node-fetch for communicating between servers. To create our new GraphQL microservice, which we’ll call graphql-server, we need to be able to do three things:

‘Introspect’ the schemas from our other microservices, which means to send them a GraphQL request which simply returns information about the schema
Turn the responses from the introspection queries into a schema that graphql-server can execute by delegating incoming requests to the relevant microservice
Merge all those new schemas together

Fortunately, graphql-tools has all the tools we need for each of these things!

import {
  introspectSchema,
  makeRemoteExecutableSchema,
  mergeSchemas
} from "graphql-tools"
import { HttpLink } from "apollo-link-http"
import fetch from "node-fetch"

Step 1

First, we introspect our remote schema. This is simple: we just call introspectSchema, passing in instructions about how to find the remote schema. And guess what, Apollo have a tool for creating those instructions too.

Per the graphql-tools docs, "Apollo Links are chainable 'units' that you can snap together to define how each GraphQL request is handled by your GraphQL client."

An HttpLink is a specific type of Apollo Link which describes where to find a schema, like this:

const schemaLink = new HttpLink({ uri: "https://your-api.com/graphql", fetch })
const schemaDefinition = await introspectSchema(schemaLink)

Step 2

With step 1 complete, we already have everything we need for step 2, turning information about a remote schema into a schema that graphql-server can expose to client applications.

const remoteSchema = makeRemoteExectuableSchema({
  schema: schemaDefinition,
  link: schemaLink
})

Step 3

remoteSchema is now a fully-fledged GraphQL schema, ready to receive requests. We’ll need to repeat steps one and two for each remote schema (i.e. each of our microservices), and we’ll assume the resulting schemas are in an array called remoteSchemas. All that remains is to merge them together.

const mergedSchema = mergeSchemas({ schemas: remoteSchemas })

mergedSchema is a single schema that contains all the individual schemas from steps one and two, meaning it can execute any query or mutation that any of the remote schemas could execute. And it will do so by delegating the query or mutation to the microservice whose schema originally defined it.

And that’s all there is to it! Just create a GraphQL server with mergedSchema and expose it on an HTTP endpoint and you’re good to go.

Summary

We’ve covered a lot of ground here and achieved a lot of cool stuff, so let’s recap. We have:

Fetched data from each of our microservices about their GraphQL schemas and created links to them which will be used to delegate requests to them
Turned all that data and those links into GraphQL schemas which are executable remotely
Merged the new schemas together

…all of which allows us to:

Expose a single GraphQL endpoint that provides access to the functionality of all our whole application
Scale our microservices separately
Develop any given microservice without affecting any other

…all at the same time!

We’ve been using this sort of architecture in production for about 18 months now and we’re improving and refining it all the time. For our clients’ software and our internal applications, we’ve found that the GraphQL microservices architecture has helped us develop quick and reliable software quickly and reliably.

DEV Community: Jake Dowie

Password Security in 2022 - What you need to know

Why password security is important

How to improve password security

What does a strong password look like?

Password managers

In-browser password managers

3rd party password managers

Multi-factor authentication (MFA)

Single sign-on

Passwordless authentication

React component testing with Jest and React Testing Library

Why Jest and RTL (React Testing Library)?

What to test?

How to write a test?

What is happening in the example above?

There will be times when the component being tested will require a wrapper: Memory Router or a context to render successfully. Take a look at the example below:

Summary

More on the topic:

GraphQL microservices - Combining data from multiple microservices

Introduction

The benefits and the conflict

The solution

The implementation

Step 1

Step 2

Step 3

Summary

There will be times when the component being tested will require a `wrapper: Memory Router` or a `context` to render successfully. Take a look at the example below: