Реактивная проверка крюка - PullRequest
Новая
       7

Реактивная проверка крюка

2 голосов
/ 08 января 2020

У меня есть следующее: 

const Repairs: React.FC<RepairsProps> = ({repairs, repairsPropertyLoad}) => {
  const { t } = useTranslation()
  const [isARepair, setRepair] = useState(true)
  const handleOnClick = () => { 
    setRepair(false)
    repairsPropertyLoad('token')
  }

  return ( isARepair ? <p>on</p> : <p>off</p> )
  ...

, так как это также подключенный компонент, я добавил следующий тест: 

describe('Repairs', () => {
  let store: any
  let component: any

  beforeEach(() => {
    store = mockStore({
      repairs: mockRepairs
    })

    store.dispatch = jest.fn()

    component = render(
      <Provider store={store}>
        <Repairs />
      </Provider>
    )

  })

  it('should render the Repairs component correctly', () => {
    expect(component).toMatchSnapshot()
  })

  it('should find the repair button in the document', () => {
    const { getByText } = component

    const repairsButton = getByText('Repair')
    expect(repairsButton).toBeInTheDocument()
  })
})

как я могу проверить isARepair флаг сценар ios (true и false), чтобы я мог сделать снимок либо off, либо on результатов?

1 Ответ

3 голосов
/ 08 января 2020

Я настоятельно рекомендую вам написать тест, как если бы конечный пользователь использовал ваш пользовательский интерфейс. Например, вы устанавливаете setIsRepair в false, когда пользователь нажимает кнопку. Вы можете смоделировать нажатие кнопки, используя fireEvent: 

fireEvent.click(repairsButton);
expect(getByText('off')).not.toBeNull();
// this might not be the exact code but you get the gist

Если вы хотите протестировать свои хуки, вы должны создать пользовательский хук, сделать его фиктивным тестовым компонентом и проверить возвращаемые значения; или используйте Библиотека тестирования React Hooks . Однако, если ваша логика состояний c так же проста, как и одна useState, я бы посоветовал не тестировать ее, потому что вы будете по сути проверять использование React useState вместо тестирования собственной логики состояний c. Моя рекомендация состоит в том, чтобы проверить логику состояния c, которая состоит из многих частей (она достаточно сложна, что требует проверки).

...