Как эффективно (не) тестировать сервисный слой - PullRequest
Новая
       25

Как эффективно (не) тестировать сервисный слой

1 голос
/ 23 сентября 2010

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

public void acceptRequest(User from, User to) {
    rosterDAO.acceptRequest(from, to);
}

Юнит-тест для этого метода выглядит так 

private final RosterDAO rosterDAO = context.mock(RosterDAO.class);
...
public void testAcceptRequest() {
context.checking(new Expectations() {{
    oneOf (rosterDAO).acceptRequest(from, to);
    will (returnValue(1));
}
});

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

Так что для всех вас, гуру TDD, которые настаивают на 100% покрытии:

Какую ценность вы видите в этом тесте, приносимом в проект?

Как я мог бы написать это лучше?

Ответы [ 3 ]

3 голосов
/ 23 сентября 2010

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

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

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

ИМХО 100% покрытие модульных тестов почти всегда нереально и не нужно в реальных проектах. Обычно есть достаточное количество, например, код обработки исключений, который сложно протестировать и тривиален, поэтому, по моему опыту, он может не просто стоить усилий. Сначала сосредоточьтесь на наиболее важных деталях, используя свои ограниченные ресурсы для получения максимальной выгоды . Если такие методы являются наиболее интересными частями кода, оставшимися непроверенными, и у вас все еще есть время и энергия, чтобы покрыть их, вы также можете пойти и обойти свой набор тестов :-) Однако, я боюсь, что большинство реальных проектов далеки от этого уровня дилемм: - (

2 голосов
/ 23 сентября 2010

Сколько дополнительной сложности потребуется, чтобы сделать эти тесты интересными?

Здесь есть три вещи, которые могут быть неправильными: выбор rosterDAO из всех других ваших DAO, которые вы можете иметь, и два передаваемых вами параметра: from и to, которые можно, например, транспонировать без какой-либо ошибки компиляции. , Похоже, что у вас, похоже, нет обработки исключений (верно?), Поэтому я согласен, что это довольно минимальный случай.

Однако, если бы здесь было что-то вроде дополнительной логики, например, каких-либо условий при выборе DAO или передаваемых параметров, я бы, конечно, хотел бы провести несколько тестов.

Итак, глядя на ваш проект в целом, этот метод типичен? Предположим, у вас было 20 методов, и 19 из них имели , имели условия и поэтому заслуживали тестирования. В этом случае я бы просто оставил все в порядке и протестировал бы этот метод - это вряд ли какая-то работа.

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

1 голос
/ 23 сентября 2010

Вероятно, бессмысленно создавать модульное тестирование этого конкретного метода, поскольку в нем нет валидации или бизнес-логики (валидация, вероятно, на уровне rosterDAO). Однако вы должны создать интеграционные тесты метода, используя реальный rosterDAO, а не фиктивный.

...