Модульное тестирование метода, который обновляет только некоторые свойства

Question

Я хочу провести модульное тестирование метода, который устанавливает для свойства active класса Person значение True.

У класса Person есть много других свойств:

public class Person{
    private int id;
    private Boolean active;
    private Boolean adult;
    ... more properties

    ... getters and setters
}

Метод тестирования будет выглядеть примерно так:

public void updatePersonStatus(int personId){
    Person person = getPersonById(personId);
    person.setActive(true);

    repository.save(person);
}

Достаточно ли проверить только то, что метод save вызывается с объектом person, у которого свойство active true (пример с использованием mockito):

    @Test
    public void activateTest() {
        ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class);
        Person testPerson = new Person();
        testPerson.setActif(true);

        responsableExamenService.updatePersonStatus(1);

        verify(theClass, times(1)).save(argument.capture()); //verify that the method save is called one time with a class Person as a parameter
        assertTrue(argument.getValue().getActive()); //and that the Object person have a property active to true.
    }

Или мне также нужно проверить, что все остальные свойства Person не были изменены bean-компонентом?

Другими словами, должен ли модульный тест проверять «что должен делать метод», или нужно ли проверять только то, что должен делать метод, не проверяя возможные побочные эффекты? Здесь примером побочного эффекта будет помимо установки active в значение true, разработчик может также установить свойство adult в значение true.

PS: пример на Java, но вопрос применим почти ко всем языкам программирования

Answer 1

К сожалению, набор функций, которые не должна выполнять функция, бесконечен.Не установка других, кроме желаемых атрибутов - это только одна возможность.И, когда дело доходит до спецификаций, они в основном только явные в отношении того, что должна делать функция.Всегда есть неявное «и ничего больше», и лишь в редких случаях некоторые выбранные поведения явно исключаются.

С другой стороны, когда вы применяете модульное тестирование, чтобы проверить, что написанный вами код ведет себя так, как вы намеревалисьЕсли он будет вести себя правильно, то проблема станет управляемой: существует множество «вероятных» ошибок, и ваши тесты должны быть разработаны для их выявления.Например, вы знаете, выполняет ли ваш код ввод-вывод или нет, и если нет, то при написании юнит-тестов нет смысла проверять, не выполняет ли ввод-вывод.С другой стороны, если у вас есть веские основания полагать, что, скорее всего, ошибка заключается в том, что код выполняет больше, чем предполагалось, для определенной операции, то стоит проверить, что это не так.

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

Answer 2

Простой ответ - строгого правила не существует. Модульное тестирование означает тестирование одного «модуля» функциональности.

В вашем случае функциональность "обновление статуса человека". Это должно быть определено спецификацией - что ожидается в этом случае. И в идеальном мире ваши тесты должны проверять только указанные вещи.

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

Answer 3

Правило, которому я лично следую, - это сначала проверить, что должен делать метод.Я протестирую что-то вроде «без побочных эффектов» тогда и только тогда, когда с точки зрения реализации метода имеет смысл применять такой эффект (но не должен) или (придерживаясь одного из правил TDD), когда яДоказательство того, что код работает (обращаясь к вашему примеру - сначала я бы не проверял отсутствие такого побочного эффекта, но , если бы какой-нибудь разработчик установил другое свойство на true - я докажуошибка, написав юнит-тест, который проверяет этот побочный эффект, а затем я приму исправление).