Я должен записать модульный тест на метод в классе обслуживания, который только называет метод в классе репозитория?
Обращаясь к ответу Дэна Дайера, попробуйте зарегистрировать OnSelectListener в методе post(Runnable):
spinner.post(new Runnable() {
public void run() {
spinner.setOnItemSelectedListener(listener);
}
});
Сделав это для меня, желаемое поведение, наконец, произошло.
В этом случае это также означает, что слушатель запускает только измененный предмет.
5 ответов
Да, я бы определенно написал модульный тест для уровня обслуживания. Причина этого в том, что вы не только проверяете, что ваша реализация работает сейчас, но вы также проверяете, что она будет работать и в будущем.
Это жизненно важная концепция, которую необходимо понять. Если позже кто-то придет и изменит ваш ServiceLayer, а модульного теста нет, как вы можете убедиться, что функциональность продолжает работать?
Я бы также написал тесты для вашего DAL, но я бы поместил их в отдельную сборку под названием DataTests или что-то в этом роде. Цель здесь - изолировать ваши проблемы от сборок. На самом деле модульные тесты не должны касаться вашего DAL.
Кроме того, если бы вы создали этот код с помощью TDD, у вас был бы тест. На самом деле имеет значение, могут ли люди вызывать Delete через вашу службу, поэтому вам действительно нужно протестировать его.
Да, оба.
IMyRepository mock = ...;
// create Delete(int) expectation
MyService service = new MyService(mock);
service.Delete(100);
// Verify expectations
Ваш метод Delete прямо сейчас может вызывать только метод Delete в репозитории, но это не значит, что так будет всегда. Вы хотите иметь модульные тесты для этого частично, чтобы убедиться, что он работает правильно, а частично как способ определения ваших спецификаций того, как должен работать репозиторий.
У вас также должен быть тест, который проверяет, что конструктор выдаст исключение, если репозиторий имеет значение NULL. У вас также может быть другая проверка, которую нужно выполнить здесь, в этом методе, например, неотрицательный идентификатор или ненулевой идентификатор. Может быть, здесь этого не происходит, сделайте это частью спецификаций, создав тесты, которые проверяют ожидаемое поведение.
Они кажутся тривиальными, но я могу почти гарантировать, что однажды это изменится, и ваши ожидания и спецификации могут быть не проверены.
Создайте тест для службы. В настоящее время все, что он делает, это вызывает метод удаления репозитория; однако вы не должны об этом заботиться. Что, если потом что-то случится и функциональность станет намного сложнее? Разве вы не хотите иметь код модульного теста, который убедит вас, что функциональность по-прежнему работает должным образом?
Если вы раскрываете свой Delete через свой Сервис, вы ожидаете, что это даст эффект. Напишите модульный тест, чтобы проверить этот эффект. В зависимости от ваших конкретных потребностей, я бы сказал, что вам может не понадобиться тест на удаление репозитория, особенно если эта функция реализуется как часть вашей функции удаления службы, но на самом деле все зависит от того, какой уровень охвата вы ' пытаюсь за.
На мой взгляд, вам нужно протестировать оба. Возможно, вы можете создать класс контекста EF в отдельной фабрике, которую можно будет проще протестировать, и имитировать класс контекста для тестов MyRepository. Это будет проще, и использование фабрики для создания контекстных вызовов кажется мне весьма полезным.