Чтобы исправить ошибку в приложении, я изменил метод с именем postLogin, добавив вызов к существующему методу с именем getShoppingCart.
Код
protected void postLogin() {
getShoppingCart();
}Однако я не уверен, для чего лучше всего написать модульный тест postLogin.
Подход 1
Используйте команду verify from Mockito, чтобы просто убедиться, что метод был вызван.
verify(mock).getShoppingCart();Подход 2
Проверьте побочный эффект вызова метода, выбрав значение пользовательской корзины.
AssertNotNull(user.getShoppingCart());Один подход лучше другого?
getShoppingCart()метода нет побочных эффектов, вам не нужно проверять, как он называется. Если у него есть побочные эффекты, вы должны действительно изменить его имя, потому чтоgetXXX()методы обычно должны быть идемпотентными.getNextValue? Можно утверждать, что кто-то может сказать: «Не называйте это получателем; измените имя наnextValue», но я уже видел егоgetNextраньше. Возможно, лучшим примером будет объект, представляющий электрон; что происходит, когда я звонюgetPosition? Или хуже,getPosition(); getVelocity();Ответы:
Я обычно предпочитаю метод 2.
Почему? Потому что вы хотите
postLoginизменить какое-то состояние вашей системы, но то, как она это выполняет (и какие методы она вызывает для этого внутренне), - это просто деталь реализации, в которой ваш модульный тест не должен делать никаких предположений. Так что лучше сделайте свой тест, просто проверив окончательное состояние.источник
Я бы поменял getShoppingCart на что-то вроде initializeShoppingCart, цель метода должна быть понятна любому, кто его читает, без необходимости проверять, что делает метод, и побочные эффекты, подобные этому, могут вызывать удивительное поведение у пользователей метода.
Если getShoppingCart находится в другом классе, и он уже тестируется модулем, я бы использовал подход 1 - нет необходимости снова проверять то, что уже проверено. В этом случае мы уверены, что getShoppingCart работает правильно, и мы только хотим убедиться, что он вызывается из postLogin, поэтому, если кто-то в будущем удалит этот вызов, тест не пройдёт.
Если getShoppingCart является закрытым методом, который не может быть протестирован сам по себе, то я бы использовал подход 2, чтобы убедиться, что при вызове postLogin требуемая функциональность getShoppingCart выполняется должным образом.
источник
При тестировании вызова функции (void or not), который имеет побочный эффект, наиболее полно проверить, что побочный эффект не только возникает, но и проверить, что побочный эффект (выход системы или изменение состояния) является желаемым.
источник
Я не буду обсуждать ваш дизайн, но в вашем случае я бы выбрал первый подход, потому что модульное тестирование предназначено для проверки того, какие методы технически выполняют независимо от их работы в области, то есть что
postLoginделает ваш метод ? Технически это вызывает,getShoppingCardтак что вам нужно проверить, что на самом деле вызываетgetShoppingCard, я бы также создал еще один тест дляgetShoppingCardпроверки того, что он делает, и если у него есть побочные эффекты, я проверим его внутри этого нового теста.источник
У вас есть ошибка в postLogin. Итак, первое, что вы должны сделать, это создать модульный тест, который при вызове postLogin без ожидаемого набора информации «провалится».
Исходя из вышеприведенной идеи, другой альтернативой из предложенных 2 является введение информации о корзине покупок в качестве параметра. Если у вас нет правильной информации, вы бросаете непроверенное исключение. Это даст понять, что без правильных деталей ваш метод обречен.
Это потребует небольшого изменения, когда клиент, вызывающий postLogin прямо сейчас, должен также передать информацию о корзине. Для меня это все еще понятно, когда вы видите, что они связаны. Это соединение будет сделано вызывающей стороной.
Тогда вам даже не нужно тестировать getShoppingCart внутри postLogin, потому что реальным тестируемым методом является postLogin. Это тот, который имеет ошибку и единственный, который требует надлежащего исправления и проверки. С введенной зависимостью вы сможете легко протестировать ее в других условиях и подтвердить, что ошибки не выдается.
источник