JEST для тестирования компонентов реакции

Question

Я слежу за учебником по шутке о том, как тестировать мой компонент, и мне интересно, не упускаю ли я чего-нибудь. Я пытаюсь протестировать свой weatherApp.js, единственная цель которого - отобразить информацию из моего TemperatureData.js с цветом из моего colorize.js

export default class Weather extends React.Component {
    constructor(props) {
        super(props);
        this.state = {temp: undefined}}
    componentDidMount() {temperatureData().then(temp => {this.setState({temp: temp})})
    }
    render() {
        const temperature = this.state.temp;
        return <>{this.state.temp === undefined ?<somegraph />:<p style={{ color: colorize(temperature) }} id="temperature">{temperature}</p>}</>
    }
}

Вот что мне нужно для тестирования этого приложения, я ' Я не уверен, нужно ли мне тестировать что-то еще или что еще мне не хватает, любой ввод приветствуется.

describe("<WeatherApp> component test", () => {
  test("displays data from temperature data", async () => {
    const mockedTemp = "something irrelevant";
    temperatureData.mockImplementation(() => {
      return Promise.resolve(mockedTemp)
    })
    const weatherComponent = render(<WeatherApp />);
    expect(temperatureData).toHaveBeenCalled()
    await wait(() => {
      const paragraph = weatherComponent.getByText(mockedTemp)
      //console.log(paragraph)
      expect(paragraph).toBeInTheDocument()
      expect(paragraph).toBeDefined()
    });
  })
})

Я не уверен, должен ли я проверять, вернется ли правильный цвет на основе моего ввода температуры поскольку у меня есть отдельный модульный тест для моего файла раскраски ...

Answer 1

Достаточно ли вашего модульного теста, зависит от того, что вы определяете как критические критерии для своего компонента. Если критически важно убедиться, что температура отображается правильным цветом, вы, вероятно, должны это проверить. Однако, как вы сказали, у вас есть отдельный тест для функции раскрашивания, так что этого может быть достаточно. Если это дает вам уверенность в том, что он будет работать, нет необходимости проверять его снова в weatherApp.js

Эти решения относительно субъективны и являются одной из причин, по которым модульное тестирование является сложной задачей. - относительно мало предписывающих ответов, что тестировать. Для лучшего руководства, это довольно хорошее чтение по теме .

Однако есть способы структурирования ваших компонентов, которые облегчают модульное тестирование, и в этом отношении у меня есть предложение по изменению способа построения вашего компонента, поскольку на самом деле, я думаю, вас волнует следующее:

• Компонент WeatherApp отображает цветные данные температуры

Справа ? Вам на самом деле не важно, что он вызывает API ... данные могут поступать откуда угодно. И вы на самом деле не заботитесь о том, что он вызывает функцию colorize ... только о том, что применяется цвет. Тестирование этих деталей только делает ваш модульный тест хрупким, что означает, например, что вам придется обновить определение модульного теста, если ваш API изменится.

Вместо этого сделайте компонент WeatherApp без состояния и презентационным. Используйте родительский компонент для обработки:

1. Вызов API
2. Расчет цвета
3. Отрисовка WeatherApp

class ParentComponent extends React.Component {
    constructor(props) {
      super(props);
      this.state = {
        temp: undefined,
        color: undefined,
      }
    }

    componentDidMount() {
      temperatureData().then(temp => {
        this.setState({
          temp: temp
          color: colorize(temp)
        })
      })
    }

  render(
    return (
      <WeatherApp temp={this.state.temp} color={this.state.color} />
    )
  )
}

Тогда ваш тест будет выглядеть примерно так:

describe("<WeatherApp> component test", () => {
  test("displays data from temperature data", () => {
    const mockedTemp = "something irrelevant";

    const weatherComponent = render(<WeatherApp temp={mockedTemp} />);

    const paragraph = weatherComponent.getByText(mockedTemp)
    expect(paragraph).toBeInTheDocument()
  })
})

Вы можете включить цвет в тест или нет ... на ваше усмотрение.

Так как вы можете протестировать все 3 units (temp / color / weatherApp), которые составляют родительский компонент отдельно, вы можете быть относительно уверены, что родительский компонент будет работать. У вас также есть дополнительный бонус в виде отсутствия необходимости писать какой-либо асинхронный код в модульном тесте.

Answer 2

Вы можете настроить jest для отчета тестового покрытия информации, добавив параметр --coverage=true в вашу тестовую командную строку:

jest --coverage=true

Тестовое покрытие даст вам первую подсказку того, что отсутствует в ваших тестах.

Например, если вы забыли протестировать условный рендеринг на основе тернарного оператора (как в данном случае, вы не проверяете это, если this.state.temp равно undefined , <somegraph /> должен отображаться), отчет о покрытии ( что-то вроде этого ) даст вам непокрытых строк , что является отличным индикатором, чтобы узнать, если вы забыли протестировать некоторые основные c logi c вашего компонента.

Однако тестовое покрытие может не знать о некоторых дополнительных логиках c, таких как побочные эффекты или css стиль и т.д. c .. Иногда вы Мне нужно подумать немного дальше, чтобы протестировать более подробные c logi c в ваших компонентах.

Я предлагаю вам начать с проверки того, что у вас нет непокрытых строк, просмотрев отчет о покрытии. Надеюсь, это поможет!