Блог

Я не могу понять весь процесс тестирования

Это понятно. Тестирование и обеспечение качества программного обеспечения — огромная профессиональная область (это больше, чем тестирование видеоигр!)

Я использую библиотеку тестирования, и мне комфортно тестировать только тексты, метки, и я чувствую, что мне не нужно тестировать какую-либо реализацию в React или Redux

Это неправильное отношение. То, что вы описываете, является очень нестрогим, небрежным, случайным и, самое главное, поверхностным тестированием.

Просто потому, что данные на экране компьютера пользователя отображаются правильно, это не значит, что это действительно так. Откуда вы знаете, что вы на самом деле не взаимодействуете с mocked UI или что внутренняя база данных действительно содержит новые данные? Или что не было никаких негативных побочных эффектов (например, система удаляла все остальное — и да, это случилось со мной однажды …).

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

Теперь, если все тексты, метки, отображаемые значения в моих тестах верны, это означает, что все должно быть в порядке

Нет, это не так. Смотрите выше.

но, к сожалению, когда я использую Redux, я всегда вынужден тестировать реализации Redux (издеваясь над хранилищем, издеваясь над редукторами и т. Д.) И асинхронное поведение, такое как выборка данных и так Далее.

ДА. Вас заставляют делать правильные вещи. Это называется ямой успеха. Не сопротивляйтесь этому. Это к лучшему. Эти библиотеки, платформы и фреймворки разрабатываются людьми с большим опытом в разработке программного обеспечения, чем у нас обоих, поэтому, если они говорят нам что-то делать, мы должны делать то, что они говорят — если мы не согласны, нам нужно формализовать наши возражения и изложить их в вопросах GitHub с академической строгостью, а не в сообщениях о переполнении стекаутверждать, что что-то не нужно, потому что вам просто не хочется. Приношу извинения за прямоту, но я надеюсь, что вы никогда не будете работать в критически важной для безопасности отрасли или секторе, пока ваше отношение не изменится, потому что я никогда не хочу видеть еще один инцидент Therac-25, который был напрямую вызван людьми, разделяющими ваше отношение к тестированию программного обеспечения.

Зачем мне нужно и я вынужден тестировать реализации Redux, если я могу просто проверять отображаемые значения, а пройденные тесты всегда будут указывать, что реализации Redux работают правильно в моем проекте?

Потому что то, что вы описываете, не обеспечивает даже близкого к полному охвату кода.

Вот несколько разных вещей, которые следует учитывать:

• Тестирование программного обеспечения (и системное тестирование в целом, в любой области) обычно можно разделить на эти категории:

  • Модульное тестирование: тестирование отдельной «единицы» вашего кода в изоляции от всего остального.
    • (Примечание: многие люди в настоящее время злоупотребляют фреймворками модульного тестирования, такими как xUnit и MSTest, для реализации того, что на самом деле является интеграционными тестами, поэтому многие люди не понимают реальной разницы между интеграционными и модульными тестами, что удручает …). «Unit» будет чем-то вроде single class или function , нецелое приложение с графическим интерфейсом.
    • Ваша текущая стратегия тестирования — это не модульный тест, потому что вы ничего не тестируете изолированно: вам нужно запустить все приложение, включая конвейер React / Redux, веб-сервер и чрезвычайно сложное, многомиллиардное приложение для веб-браузера с графическим интерфейсом.
    • Вообще говоря: «если вам нужны конкретные зависимости (вместо подделок или макетов) для тестирования чего-либо, это не модульный тест, это интеграционный тест».
  • Интеграционное тестирование: тестирование нескольких компонентов, которые взаимодействуют друг с другом.
    • Это довольно абстрактное определение, но оно может означать такие вещи, как тестирование кода бизнес-логики приложения, когда он связан с (копией!) вашей производственной базы данных. Это может также включать тестирование бизнес-уровня, когда к нему подключен графический интерфейс, но тестирование графического интерфейса нелегко автоматизировать — многие, но не все, люди не будут рассматривать то, что вы делаете, как модульный тест, тем более что то, что вы описали, подразумевает, что ваши тесты не тестируютдля побочных эффектов или проверки других изменений состояния в другом месте системы (например, в базе данных или серверной веб-службе).
  • Существуют и другие типы тестов, помимо модульных и интеграционных, но это два основных типа полностью автоматизированных тестов, которые должны быть у каждого приложения, и каждое приложение должно иметь хорошее покрытие кода, особенно из модульных и интеграционных тестов. Обратите внимание, что покрытие кода не подразумевает исчерпывающую полноту, и достижение 100% покрытия кода часто является пустой тратой времени, если этот код включает в себя тривиальные реализации, такие как шаблонный код, или код проверки параметров, или код, сгенерированный инструментом, который сам по себе очень хорошо протестирован.
    • Вообще говоря: если фрагмент кода «сложный» или регулярно изменяется, он должен иметь «хороший» (75% ? 80%? 90%?) покрытие кода.

• Поскольку тестирование программного обеспечения с помощью графических интерфейсов очень сложно (и хрупко: поскольку графические интерфейсы, вероятно, являются той частью, которая больше всего подвергается серьезным изменениям в любой программной системе, ориентированной на пользователя), на самом деле оно часто не подвергается автоматическому тестированию в той мере, в какой должно — вот почему важно обеспечить хороший охватчасти, не связанные с GUI, с автоматическим тестированием, что также уменьшает количество ручного тестирования GUI, которое необходимо выполнить.

• Наконец, важная вещь, которую следует учитывать при использовании шаблона Redux, в частности, заключается в том, что Redux не является специфичным для приложений с графическим интерфейсом. Теоретически вы должны иметь возможность использовать приложение Redux, скопировать и вставить его на стороне сервера Node.js Приложение на JavaScript и подключите его к виртуальному DOM, и вуаля, вашему приложению больше не требуется клиентский JavaScript для работы! Это также означает, что вы можете получить отличное покрытие кода вашего приложения, просто используя специальный виртуальный DOM, предназначенный для тестирования, а не реальный DOM браузера — но ваш текущий подход не будет работать с этим, потому что вы говорите только о проверке изменений в реальном DOM браузера, а не в виртуальном DOM.