Что поблочное тестирование значит для Вас?
У вас есть A и B в вашем магазине. C является производным от A и B, поэтому, если A изменится, вы захотите восстановить C и положить его в свой магазин. После этого вы можете получить компонент prop E, полученный из C и D. Действие x меняет A, и теперь вам нужно новое значение для C или E, и это трудно сделать за один шаг, не усложняя редукторы.
Есть три основных подхода, которые я использовал для подобных сценариев, и какой я бы порекомендовал, зависит от специфики сценария. Все это просто разные подходы к тому, как / когда / где определять C (и могут быть распространены на дальнейшие выводы, такие как E).
Подход 1 Рассчитать C в промежуточном программном обеспечении, предназначенном для борьбы с побочными эффектами действий.
Этот подход наиболее похож на тот, который у вас уже есть. Он просто перемещает его из компонента, поэтому вы не боретесь с взаимодействием между вашим магазином и тем, как методы жизненного цикла получают новую информацию. Для этого подхода я бы использовал Redux Saga, чтобы он обрабатывал C в ответ на действие x и отправлял действие, чтобы обновить хранилище новым значением для C. Это легко сделать (если вы прошли начальную кривую обучения Redux Saga), поскольку Redux Saga получает действие после того, как магазин уже обновлен. Основным недостатком этого подхода является то, что ваш магазин будет временно находиться в несогласованном состоянии, где C еще не отражает изменения в A. Для некоторых сценариев это важно, а для некоторых - нет. Другим потенциальным недостатком является то, что если вы еще не используете Redux Saga, это может поначалу быть немного пугающим, потому что использование функций генератора и yield, а также всего мышления при использовании Redux Saga может показаться немного чуждым (но я очень люблю использовать Redux Saga для сложных асинхронных сценариев).
Подход 2 Рассчитайте C в создателе действий.
Это обычно включает использование thunk для первоначального ответа на действие x, и thunk может затем получить B из хранилища, вычислить C и отправить действие с полезной нагрузкой, которая содержит две части - одна использованная редуктором для A и одним редуктором для C. Основным недостатком этого подхода является то, что если существует несколько способов изменения зависимостей для C (то есть A и B), это может стать сложным способом организации вещей, но для некоторых сценариев он может работать нормально , В основном я отошел от этого подхода в пользу двух других подходов.
Подход 3 Не кладите C в свой магазин.
Если C полностью получено из других вещей в вашем магазине, то в действительности это не обязательно должно быть в магазине. C - это просто просмотр другой информации в вашем магазине. Вместо этого вы можете использовать селектор для этой цели. Если вывести C дорого, используйте запомненный селектор. В более сложном случае наличия E, полученного из C и D, селектор для E может использовать селектор для C при получении D из магазина. Это тот подход, который я обычно одобряю, если нет веских причин для C быть в магазине. Такой подход позволяет вашим редукторам оставаться простыми и независимыми, сохраняя ваш магазин в согласованном состоянии.
Другие подходы
Есть и другие способы сделать это, но 3 подхода выше - это те, которые я действительно использовал сам. Еще один способ - использовать редуктор, который использует другие редукторы. В этом подходе редукторы для A и B будут использоваться редуктором, который затем вычисляет C и возвращает состояние со всеми тремя частями информации. Существуют пакеты для облегчения составления редукторов таким образом, но я не использовал их, потому что меня не очень интересует этот подход. Для меня это просто неправильное место, чтобы описать эту сложность.
12 ответов
Я пытаюсь реализовать модульные тесты для тестирования только отдельного метода. и я прилагаю усилие к классам "насмешки" Крита для подчиненных классов и методов, используемых методом, который я тестирую...... так, чтобы осуществление кода в том методе на самом деле не называло код в других методах, которые модульный тест, как предполагается, не "Тестирует" (Существуют другие модульные тесты на те методы), Таким образом, отказ модульного теста надежно указывает на отказ метода, который тестирует модульный тест...
Ложные классы разработаны для "моделирования" интерфейса и поведения подчиненных классов так, чтобы метод, который я тестирую, мог назвать их, и они будут вести себя INA стандартный, четко определенный путь согласно системным требованиям. Чтобы заставить этот подход работать, вызовы к таким подчиненным классам и к их методам должны быть выполнены в четко определенном интерфейсе, так, чтобы процесс "тестера" мог "ввести" Ложную версию подчиненного класса в класс, протестированный вместо фактической производственной версии.... Это отчасти похоже на шаблон общего умысла, называемый "Внедрением зависимости", или "Инверсией Управления" (МОК)
Существует несколько сторонних инструментов на рынке, чтобы помочь Вам реализовать этот вид шаблона. Один я услышал о, назван "Ложным Носорогом" или что-то как этот...
Править: Rob Wells. @Charles. Спасибо за это. Я забыл использовать фиктивные объекты для завершенной замены использования других классов за исключением того под тестом.
Несколько других вещей, которые я помнил после Вас упоминающий фиктивные объекты, состоят в том что:
- они могут использоваться для моделирования ошибок, возвращаемых включенными классами.
- они могут использоваться для повышения определенных исключений для проверки обработки исключений в класс под тестом.
- они могут использоваться для моделирования объектов, где стоимость установки высока, например, большой SQL бэкэнд DB.
- они могут использоваться для проверки контента входящего запроса.
Для получения дополнительной информации взгляните на статью Martin Fowler, названную "Насмешки, Не Тупики" и статья "Mock Objects" Прагматически настроенных Программистов
Нет никакой причины, почему модульные тесты не могут охватить несколько классов или даже подмодули, пока тест рассматривает только одну последовательную работу предприятия. Думайте о "calculateWage", методе ФИЛИАЛА, который использует различные стратегии вычислить зарплату человека. Это - один модульный тест, по-моему.
Существует различие между процессом, который Вы используете для теста и технологии, которая используется для поддержки его. Различные платформы, используемые для поблочного тестирования, обычно очень гибки и могут использоваться для тестирования небольших единиц кода, больших единиц и даже тестирования всех процессов. Эта гибкость может привести к беспорядку.
Моя рекомендация состоит в том, что безотносительно определенной методологии или процесса Вы принимаете это, Вы выделяете различный Модульный тест в отличные блоки или модули. Точное расположение зависит от Вашего кода и организации Вашей компании.
Накапливаемый эффект использования платформы Модульного теста является так большой частью тестирования кода, автоматизирован. Принятый правильно разработчики могут оценить изменения в коде кода лучше с прохождением через полного процесса Вопросов и ответов. Что касается самой Q & A Process это делает их время более продуктивным, поскольку качество кода, выходящего из разработки, должно быть выше.
Поймите, что это не ответ на все проблемы качества это просто полезный инструмент как другой, Вы используете.
Модульные тесты обычно используются разработчиками для тестирования изолированных разделов кода. Они покрывают случаи границы, ошибочные случаи и нормальные случаи. Они предназначаются для демонстрации правильности ограниченного сегмента кода. Если вся Ваша передача модульных тестов, то Вы продемонстрировали, что Ваши изолированные сегменты кода делают то, что они, как предполагается, делают.
Когда Вы делаете интеграционное тестирование, Вы смотрите на сквозные случаи, чтобы видеть, сотрудничают ли все сегменты, которые передали поблочное тестирование. Проверки функционального тестирования, чтобы видеть, отвечает ли код требованиям, как указано. Приемочные испытания сделаны конечными пользователями, чтобы видеть, одобряют ли они конечный продукт.
Я услышал о методах, в которых многие модульные тесты сделаны сначала, и разработка сделана вокруг них. Кто-то только что прокомментировал высказывание, что это - "Разработка через тестирование" - TDD (Спасибо Elie).
Но если это - офшорная операция, это возможно собирается заряжать Вас больше денег, потому что они проводят время, делая эти модульные тесты - затем я был бы осторожен. Получите второе мнение от кого-то, испытанного с модульными тестами, кто проверит, что они на самом деле делают, как они говорят.
От моего понимания поблочное тестирование добавит немного больше времени к любому проекту разработки, но конечно может предложить некоторый контроль качества. Тем не менее, это - тип контроля качества, который я хотел бы с в проекте дома. Это может просто быть чем-то броски офшорной компании там, чтобы дать Вам теплое нечеткое.
существует традиционное представление http://en.wikipedia.org/wiki/Software_testing как часть http://en.wikipedia.org/wiki/Software_engineering. но мне нравится идея гибкого модульного теста: тест является гибким модульным тестом, если это достаточно быстро так, чтобы программисты всегда выполняли его.
Википедия, казалось бы, предположила бы, что поблочное тестирование о тестировании самого маленького объема кода, который был бы методом на классе в случае программирования OO.
У некоторых может быть более общий термин того, что они подразумевают под модульными тестами, где некоторые могут думать о некоторых интеграционных тестах, как являющихся модульными тестами, где единица является смесью компонентов.
Модульный тест является самым маленьким и только часть уверенности, которую можно получить сами на пути к тому, чтобы быть сделанным. Какие вопросы, многократно создавая щит против регрессии и отклонения спецификации, не, как Вы на самом деле интегрируете его к своей Объектно-ориентированной архитектуре.
Это - почти повторение, "Что такое 'Единица'?" вопрос.
"Единица" может быть определена гибко. Если их документ не будет иметь определения "единицы", то необходимо будет разъяснить это.
Могло бы случиться так, что они думают о единице как о большом блоке кода. Который не является самым желательным определением.
В то время как я соглашаюсь, что у Вас есть несколько слоев тестирования (единица, модуль, пакет, приложение), я также думаю, что так большая часть этого может быть сделана с инструментами поблочного тестирования. Продвижение к, "что такое единица?" вопросы, подходящие все время.
Единица зависит от контекста. Для отдельного разработчика единицей должен быть Класс. Иногда, это будет также означать модуль или пакет.
Для команды, однако, их единица может быть пакетом или законченным приложением.
Что имеет значение, что мы думаем? Проблемой здесь является Ваше недовольство терминами, которые они используют в документе. Почему Вы не обсуждаете это с ними?
Десять лет назад, перед текущим использованием "поблочного тестирования" как тесты, записанные в коде, то же обозначение было применено к ручным тестам. Я работал на фирму по разработке программного обеспечения с очень формализованным процессом разработки программного обеспечения. Мы должны были записать "модульные тесты" прежде, чем написать любой код. В ту эру модульные тесты были записаны в текстовом документе (такой как в Word). Они описали точные шаги, которые пользователь должен был выполнить в использовании приложения. Например, они описали точный вход для ввода на странице для установки нового клиента. Или, пользователь должен был искать конкретный продукт и видеть, что отображенная информация соответствовала тестовому документу. Так, тест был сценарием, за которым следовал тестер, где они также записали результаты. Когда новое воплощение поблочного тестирования пришло, это сбивало с толку некоторое время попытка выяснить, имели ли в виду они старые, человеческие тесты или новые, кодированные тесты.
Я возглавляю группу офшорной команды также. Supposely у нас есть ряд модульных тестов..., но это не означает много.:) Таким образом, мы полагаемся намного больше на функциональное и тестеры по качеству. Наследовать проблема с поблочным тестированием состоит в том, что у Вас есть идеальное знание functionals, и Вы доверяете разработчикам. В реальном мире это трудно принять..