почему этот класс не подходит для тестирования Junit и как его улучшить? - PullRequest
Новая
       6

почему этот класс не подходит для тестирования Junit и как его улучшить?

1 голос
/ 25 мая 2020

У меня нет ответа на вопрос, но я предполагаю, что это потому, что у него есть только недействительные методы, которые в любом случае только подсчитывают. Или есть лучшее объяснение? Мне также нужно внести предложение по его улучшению. 

public class PlayingField implements Security{
    private int kidsCount;

    @Override
    public void addPerson() {
        kidsCount++;
        soundAlarm();

    }

    @Override
    public void removePerson() {
        kidsCount--;

    }

    @Override
    public int getPersonCount() {
        return kidsCount;
    }

    @Override
    public void soundAlarm() {
        if (kidsCount> 50) {
            System.out.println("cant add a kid to the PlayingField");
            kidsCount--;
        }
    }

}

методы вызываются из другого класса следующими методами: 

public class KidsShop extends FashionShop {

    private PlayingField playingField;

    public KidsShop(String name, int area, int rent) {
        super(name, area, rent);
        this.playingField = new PlayingField();
    }
    public void addKid() {
        playingField.addPerson();
    }
    public void pickUpKid() {
        playingField.removePerson();
    }
    public int getNumberOfKids() {
        return playingField.getPersonCount();
    }

Ответы [ 2 ]

0 голосов
/ 25 мая 2020

Думаю, это связано с SOLID. PlayingField инициализируется прямо внутри конструктора, и невозможно предоставить другой скорректированный PlayingField (прокси, преемник, макет и т. Д. c). KidsShop нарушает некоторые из принципов SOLID, особенно Single Responsibility, поскольку он знает, как создать экземпляр PlayingField (подумайте о внедрении зависимостей здесь через конструктор). Другой нарушенный принцип заключается в том, что PlayingField должен быть интерфейсом, взгляните на Принцип подстановки Лисков

0 голосов
/ 25 мая 2020

Я полагаю, что PlayingField сложно протестировать, потому что он обрабатывает только одно частное поле, которое невозможно смоделировать должным образом.

Поскольку nnet упоминается в комментариях, все методы, кроме soundAlarm(), могут быть протестированы.

Мое предложение по его улучшению - сделать soundAlarm() закрытым, так как он вызывается только самим классом. Или даже лучше: переместите проверочный лог c из soundAlarm() в метод addPerson. Я думаю, лучше будет проверить количество детей перед добавлением еще одного, поэтому вам не нужно будет вызывать декремент kidsCount.

...