TDD и Service (класс, что-то делать, но ничего не возвращается) - PullRequest
Новая
       17

TDD и Service (класс, что-то делать, но ничего не возвращается)

1 голос
/ 24 марта 2009

Я пытаюсь следовать TDD (я новичок) во время разработки класса Service, который создает задачи, передаваемые клиентами Service. Построенные объекты затем передаются в другие системы. Другими словами, эта служба принимает задачи, но ничего не возвращает в результате - она ​​передает встроенные задачи другим службам. Поэтому мне интересно, как я могу написать тест для этого, потому что нечего утверждать. Я думаю об использовании mocks для отслеживания взаимодействий внутри сервиса, но я немного боюсь использовать mocks, потому что я буду связан с внутренним внедрением сервиса.

Заранее благодарим всех вас!

Ответы [ 3 ]

2 голосов
/ 24 марта 2009

Нет проблем с использованием mocks для этого, так как вы фактически будете насмехаться над внешним интерфейсом компонентов, которые используются внутри компонента. Это действительно то, для чего предназначен насмешливый звук, и он звучит как идеальный вариант для вашего случая использования.

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

1 голос
/ 25 марта 2009

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

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

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

0 голосов
/ 25 марта 2009

Не уверен, какой язык вы используете, поэтому в псевдо-коде это может выглядеть примерно так: 

when_service_is_passed_tasks
  before_each_test
    mockClients = CreateMocks of 3 TaskClients
    tasks = GetThreeTasks()
    myService = new TaskRouter(mockClients)

  sends_all_to_the_appropriate_clients
    tasks = GetThreeTasks()
    myService.RouteTaks(tasks)
    Assert mockClients[0].AcceptTask(tasks[0]) was called
    Assert mockClients[1].AcceptTask(tasks[1]) was called
    Assert mockClients[2].AcceptTask(tasks[2]) was called

  if_one_routing_fails_all_fail
    tasks = GetTasksWhereOneIsFailing()
    myService.RouteTaks(tasks)
    Assert mockClients[0].AcceptTask(*) was not called
    Assert mockClients[1].AcceptTask(*) was not called
    Assert mockClients[2].AcceptTask(*) was not called
...