Можно ли вручную тестировать веб-приложения? - PullRequest
0 голосов
/ 19 июня 2020

Я изучаю TDD и пытаюсь писать тесты, следуя лучшим практикам в моих проектах. Как правило, я пишу интерфейс на React и во время обучения нашел отличную публикацию о тестировании с использованием библиотеки response-testing от Робина здесь . Я буду использовать примеры с сайта Робина, но другие примеры, которые я нашел в сети, также похожи. Итак, один из компонентов, который выполняет поиск по вводу пользователя, выглядит так:

function Search({ value, onChange, children }) {
  return (
    <div>
      <label htmlFor="search">{children}</label>
      <input
        id="search"
        type="text"
        value={value}
        onChange={onChange}
      />
    </div>
  );
}

Типичный тестовый пример для этого выглядит так:

describe('Search', () => {
  test('calls the onChange callback handler', () => {
    const onChange = jest.fn();

    render(
      <Search value="" onChange={onChange}>
        Search:
      </Search>
    );

    fireEvent.change(screen.getByRole('textbox'), {
      target: { value: 'JavaScript' },
    });

    expect(onChange).toHaveBeenCalledTimes(1);
  });
});

Мои вопросы:

  1. Разве мы не можем просто вручную протестировать этот (или аналогичный ios) сценарий?
  2. Разве не просто и интуитивно понятно go в браузере и проверить, работает ли компонент, как есть предполагается, с помощью нескольких щелчков мышью и ввода?

Единственный недостаток, который я имею в виду, - это то, что для повторения теста мне нужно снова сделать несколько кликов.

Похоже на излишество - издеваться над apis, обратными вызовами и т.д. c просто для проверки того, что компонент отображает его после определенного действия пользователя.

Конечно, мне что-то здесь не хватает. Приветствуются любые разъяснения.

Ответы [ 2 ]

1 голос
/ 19 июня 2020

У всего есть достоинства и недостатки. Преимущества TDD (разработка, управляемая поведением, модульное тестирование, тесты интеграции) следующие:

  • Вам придется писать чистый код. Я имею в виду, что ваши методы / функции будут небольшими и будут делать только одно. Вам нужно будет поддерживать cyclomati c сложность на очень низком уровне, чтобы ваши тесты были небольшими, каждая структура управления требует тестирования (если, переключатели ...). Вы избежите побочных эффектов в методах.

  • Вы сможете провести рефакторинг кода, потому что рефакторинг кода без тестов похож на изменение кода дерьмо с другим .

  • Это будет хорошо для команды и для больших проектов, вы не можете знать весь код. Любое изменение в коде может нарушить функциональность, любое исправление ошибки может привести к ряду других ошибок. TDD нам помогает.

...

...

Недостатки:

  • у вас будет для написания тестов .. больше кода.
  • вам придется больше подумать, прежде чем писать.
  • в изменяемых проектах вам придется менять не только код, но и тесты

...

...

0 голосов
/ 19 июня 2020

В общем, ручное тестирование нецелесообразно для больших приложений или в долгосрочной перспективе. Представьте себе ситуацию, в которой основной разработчик покидает команду, и никто не знает, что следует тестировать вручную. Хороший инструмент для начала - старый добрый Selenium . Он доступен для нескольких языков, вы можете начать с версии WebDriver.

...