Дизайн и тестовый подход для данного сценария - PullRequest
Новая
       23

Дизайн и тестовый подход для данного сценария

0 голосов
/ 14 августа 2010

Это не домашняя работа. Но практика, чтобы понять, каковы лучшие практики для design , implement and unit test конкретного сценария и, таким образом, discussion explaining why a particular approach was taken по сравнению с другими, была бы действительно полезна с точки зрения понимания, чтобы лучше понять, как подходить и справляться с подобными ситуациями.

Как подойти к следующему сценарию с точки зрения проектирования, реализации и модульного тестирования.

Сценарий

Динамик и слушатель общаются друг с другом. Докладчик может подарить эмоции слушателю: smile,anger, courtesy, joke, fury, etc. Слушатель дает правильный ответ на каждое сообщение (что-то сказать, атака, защита, игнорирование и т. Д.).

Вопросы

  • Какими будут правила реакции объектов слушателя?
  • Как бы это было разработано с использованием UML и реализовано путем имитации с использованием текстовых выходных данных?
  • Каким будет тестовый пример JUnit для проверки правильности реализации этого сценария?

Ответы [ 2 ]

1 голос
/ 14 августа 2010

Следующие шаги чрезвычайно важны для любой разработки.

Сбор требований

Замораживание и документирование точных требований.Составление точных примеров использования очень помогает.

Дизайн

Разработка решения.Здесь могут быть выбраны разные подходы в зависимости от характера проекта.

  • Инкрементный паттерн: для долгосрочного проекта с короткими всплесками результатов и обзоров инкрементный паттерн очень помогает.
  • Конкретный шаблон: здесь вы тщательно разрабатываете свое приложение.Циклы выпуска длиннее.Каждая функция сначала выполняется, а затем доставляется.

При использовании UML важны следующие диаграммы.

  • Диаграммы классов: следует подробно перечислить все классы.Использование интерфейса, абстрактных классов, вспомогательных классов, сторонних API-интерфейсов может быть подробно описано здесь.
  • Диаграммы последовательности: должен перечислять последовательность действий для всех перечисленных вариантов использования в проекте.

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

На самом деле здесь есть много чего описать.То, что я предоставил, - это подход, который следует использовать при реализации проекта.

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

  1. Сущность - Динамик, Слушатель
  2. Выражения - Список выражений
  3. Правила - Правила в форме реакциивыражение для выражения говорящего.
  4. Коммуникация - уровень связи, который будет использоваться говорящим для слушателя (что-то вроде трансляции) и от слушателя к говорящему (что-то вроде очереди точка-точка)
0 голосов
/ 14 августа 2010

Чтобы ответить на ваш последний вопрос (относительно JUnit), я бы реализовал следующее:

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

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

Вот введение в JUnit (возможно, немного старое, но все еще актуальное)

...