@ testing-library / реаги * TDD, реаги- bootstrap: этот тип теста полезен или просто потерял время - PullRequest
Новая
       29

@ testing-library / реаги * TDD, реаги- bootstrap: этот тип теста полезен или просто потерял время

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

Я пытаюсь написать свой код с представлением TDD, я постоянно сталкиваюсь с одной и той же проблемой, что я должен тестировать, а что нет, цель состоит в том, чтобы сделать панель навигации на основе response- bootstrap с TDD мой компонент будет просто оберткой с меньшим свойством, чтобы упростить его, я начну с фирменного дочернего компонента Navbar в реакции- bootstrap. Конечная цель состоит в том, чтобы тестирование отражало то, что пользователь должен тестировать, например, что в навигации присутствует бренд lo go img с хорошими свойствами sr c и alt.

Интересны ли такие тесты или их стоит избегать?

Мой тест 

import React from 'react';
import { render } from '@testing-library/react';
import BrandNav from './BrandNav';

test('testing brand navigation', () => {
    const altProp = 'message to show if image unavailable',
        srcProp = 'relativeFilePath',
        host = window.location;

    const { getByAltText } = render(<BrandNav alt={altProp} src={srcProp} />);

    const brandLogo = getByAltText(altProp);
    expect(brandLogo.src).toEqual(`${host}${srcProp}`);
});

Мой компонент 

import React from 'react';
import { Navbar } from 'react-bootstrap';

const BrandNav = ({ alt, src }) => {
    return (
        <Navbar.Brand>
            <img alt={alt} src={src} />
        </Navbar.Brand>
    );
};

export default BrandNav;

Ответы [ 2 ]

1 голос
/ 16 января 2020

React-тесты делятся на две категории:

  1. Утверждение, что ваши компоненты правильно соединены вместе
  2. Утверждение, что ваш компонент обрабатывает внутренние логики c правильно

Ваш тест относится к первой категории, потому что он гарантирует, что вы правильно передаете реквизиты базовому элементу HTML. Как правило, это более ценно, когда вы проходите через несколько слоев, но это хороший тест для проверки. Это довольно просто c, но это не должно мешать, и имеет смысл написать такой тест как часть процесса TDD.

Если вы обнаружите, что тест получает чем больше, чем помогает, вы всегда можете удалить его.

Примером второго типа теста может быть что-то вроде этого: 

// BrandNav.js
const BrandNav = ({ alt, src, textOnly }) => {
    return (
        <Navbar.Brand>
            {textOnly ? <span>My Brand</span> : <img alt={alt} src={src} />}
        </Navbar.Brand>
    );
};

//BrandNav.test.js
test('shows only image when textOnly is FALSE', () => {
    const altProp = 'message to show if image unavailable';
    const srcProp = 'relativeFilePath';

    const { getByAltText, queryByText } = render(
      <BrandNav
        alt={altProp}
        src={srcProp}
        textOnly={false}
      />
    );

    const brandLogo = getByAltText(altProp);
    expect(brandLogo.src).toMatch(srcProp);
    expect(queryByText('My Brand')).toBeFalsy();
});

test('shows only text when textOnly is TRUE', () => {
    const altProp = 'message to show if image unavailable';
    const srcProp = 'relativeFilePath';

    const { queryByAltText, queryByText } = render(
      <BrandNav
        alt={altProp}
        src={srcProp}
        textOnly
      />
    );

    expect(queryByAltText(altProp)).toBeFalsy();
    expect(queryByText('My Brand')).toBeTruthy();
});

Опять же, это довольно просто, но по мере усложнения логики c она скажет вам, что ваш компонент по-прежнему работает правильно, и определенно будет иметь смысл, если вы создаете свои компоненты в тестовом режиме.

РЕДАКТИРОВАТЬ: некоторые другие факторы, которые следует учитывать при попытке решить, сколько тестов вы должны написать (что может помочь ответить на ваш второй вопрос):

1. Насколько широко будет использоваться этот проект? Если это личный проект, вам, вероятно, не нужно столько тестов. Если вы пишете библиотеку, которая будет использоваться другими людьми, вам нужно гораздо более высокое тестовое покрытие. Например, react-bootstrap имеет множество простых тестов в их репозитории GitHub . Они хотят знать, не сломается ли что-либо, вплоть до самого маленького блока, поскольку многие люди полагаются на то, что их компоненты работают должным образом. Вы также можете видеть, что у них есть тесты, которые охватывают некоторые из вопросов, о которых вы спрашиваете («присутствует бренд теста»), поэтому вам не нужно писать тесты для этого.

2. Насколько вы знакомы с написанием тестов в целом? Если вы только учитесь писать тесты, я думаю, что стоит писать простые тесты, подобные этим, по нескольким причинам:

A. Вы больше познакомитесь с библиотекой тестов B. Возможно, вы в конечном итоге напишете слишком много тестов, почувствуете эту болевую точку и узнаете, каких тестов вы можете избежать в будущем.

Тесты полезны для больше, чем просто освещение. Я не могу найти его прямо сейчас, но в другом посте StackOverflow есть памятная цитата, в которой говорится: «Преимущество TDD не в том, чтобы иметь кучу тестов. Это хороший побочный эффект. Преимущество TDD должен иметь более понятный код. "

Чем больше у вас опыта написания тестов, тем больше вы будете знать, чего следует избегать. Перефразируя Кента Бека (автора «Разработка через тестирование на примере»): «Я не всегда пишу тесты для очень маленьких шагов, но когда все становится странным, приятно знать, что я могу».

0 голосов
/ 17 января 2020

Я не думаю, что такие тесты полезны. На самом деле ваше развитие не стимулирует TDD, потому что ваши тесты должны сказать вам, что делать дальше.

Я бы порекомендовал вам следовать следующему руководству: https://learntdd.in/react/

...