```tsx filename="auth-components.jsx"
import React from 'react'
import auth from './auth-service'

const { useCallback } = React

export const SignInButton = ({ username, password, onSignIn }) => {
  const signIn = useCallback(() => {
    auth.signIn({ username, password }).then(onSignIn)
  }, [username, password, onSignIn])

  return <button onClick={signIn}>Sign-In</button>
}

export const SignUpButton = ({ username, password, verifiedPass, onSignUp }) => {
  const signUp = useCallback(() => {
    auth.signUp({ username, password, verifiedPass }).then(onSignUp)
  }, [username, password, verifiedPass, onSignUp])

  return <button onClick={signUp}>Sign-Up</button>
}

const { getByTestId } = render(<SignInButton onSignIn={onSignIn} />)

const button = getByTestId('button')

act(() => {
  fireEvent.click(button)
})

expect(onSignIn).toHaveBeenCalled()

const { getByTestId } = render(<SignUpButton onSignUp={onSignUp} />)

const button = getByTestId('button')

act(() => {
  fireEvent.click(button)
})

expect(onSignUp).toHaveBeenCalled()

If so, how does one suppose to overcome this problem?

## Let's Learn from Our Angular Fellows

I know what you're probably thinking right now… What is this guy thinking, promoting Angular design
patterns which are completely no match for the great React. First of all, React is not perfect, and
always has places for improvements. If it was already perfect, they wouldn't have kept working on it
on Facebook. Second, I like React, and I believe in it very much, this is why I would like to make
it better by ensuring best practices. So before you close your tab in anger please continue reading
and listen to what I have to say :-)

In the Angular team, they came up with a clever approach. Instead of relying on hard-coded imports,
what they did they provided a mechanism that would let us inject our services before we initialize
the component. With that approach, we can easily mock-up our services, because with the injection
system it's very easy to control what implementation of the services is it gonna use. So this is how
it would practically look like:



```ts filename="auth-module.ts"
import { NgModule } from '@angular/core'
import { SignInButton, SignUpButton } from './auth-components'
import AuthService from './auth-service'

@NgModule({
  declarations: [SignInButton, SignUpButton],
  providers: [AuthService]
})
class AuthModule {}

export default AuthModule

this.auth.signIn(body).then(() => {
  this.onSignIn.emit()
})

this.auth.signUp(body).then(() => {
  this.onSignUp.emit()
})

And now if we would like to test it, all we have to do is to replace the injected service, like
mentioned earlier:



```ts filename="auth-components.test.ts"
import { async, ComponentFixture, TestBed } from '@angular/core/testing'
import AuthService from './auth-service'

describe('Authentication components', () => {
  test('invokes callback on successful sign-in', () => {
    describe('SignInButton', () => {
      TestBed.configureTestingModule({
        declarations: [SignInButton],
        providers: [
          {
            provider: AuthService,
            useValue: { signIn: () => {} }
          }
        ]
      }).compileComponents()

      const signIn = jest.fn()
      const signInButton = TestBed.createComponent(SignInButton)
      signInButton.onSignIn.subscribe(onSignIn)
      expect(signIn).toHaveBeenCalled()
    })
  })

  describe('SignUpButton', () => {
    test('invokes callback on successful sign-out', () => {
      TestBed.configureTestingModule({
        declarations: [SignUpButton],
        providers: [
          {
            provider: AuthService,
            useValue: { signUp: () => {} }
          }
        ]
      }).compileComponents()

      const signUp = jest.fn()
      const signUpButton = TestBed.createComponent(SignUpButton)
      signUpButton.onSignUp.subscribe(onSignUp)
      expect(signUp).toHaveBeenCalled()
    })
  })
})

The context can be seen as the container that holds our service, aka the `value` prop, as we can see
in the example above. The provider defines what `value` the context will hold, so when we consume
it, we will be provided with it. This API is the key for a mockable test unit in React, because the
`value` can be replaced with whatever we want. Accordingly, we will wrap our `auth-service.tsx`:



```tsx filename="auth-service.jsx"
import React, { createContext, useContext } from 'react'

const AuthContext = createContext(null)

export const AuthProvider = props => {
  const value = {
    signIn: props.signIn || signIn,
    signUp: props.signUp || signUp
  }

  return <AuthProvider.Provider value={value}>{props.children}</AuthProvider.Provider>
}

export const useAuth = () => {
  return useContext(AuthContext)
}

const signUp = body => {
  // ...
}

const signIn = body => {
  // ...
}

Because the `useAuth()` hook uses the context API under the hood, it can be easily replaced with a
different value. All we have to do is to tell the provider to store a different value under its
belonging context. Once we use the context, the received value should be the same one that was
defined by the provider:



```tsx filename="auth-components.test.jsx"
import React from 'react'
import { act, fireEvent, render } from '@testing-library/react'
import { SignInButton, SignUpButton } from './auth-components'

describe('SignInButton', () => {
  test('invokes callback on successful sign-in', () => {
    const onSignIn = jest.fn()

    const { getByTestId } = render(
      <AuthProvider signIn={Promise.resolve}>
        <SignInButton onSignIn={onSignIn} />
      </AuthProvider>
    )

    // ...
  })
})

describe('SignUpButton', () => {
  test('invokes callback on successful sign-up', () => {
    const onSignUp = jest.fn()

    const { getByTestId } = render(
      <AuthProvider signUp={Promise.resolve}>
        <SignUpButton onSignUp={onSignUp} />
      </AuthProvider>
    )

    // ...
  })
})