Как правильно писать тесты в javascript для классов и их методов?

Question

[copal]

Есть непонимание процесса написания правильных тестов. Для примера возьмем два простых класса -

class List {
    constructor(){
        this.itemAll = [];
    }

    insertItem(item){
        this.itemAll.push(item);
    }
    hasItem(item){
        return this.itemAll.indesOf(item) > -1;
    }
}

class Factory {
    constructor(){
        this.list = new List();
    }
    insertProduct(product){
        if( ! this.list.hasItem(product)){
            this.list.inserItem(product);
        }
    }
}

И вот я значит написал тест для LIst, где при добавлении мониторил длину массива, чтобы удостоверится что элемент туда добавился и так далее. Но пришло время написать тест для Factory и у меня мысли разбежались в разные стороны. То есть вот в чем дело. Добавил я продукт и что мне мониторить? Хорошо если у List будет длина, а если этот класс, который не предоставляет данные о внутренних объектах? А нужно ли мне писать тесты и для вызовов объектов находящихся в композиции? то есть вот я вызвал insertProduct, а дальше должен узнать, а был ли вызван hasItem и что в него передано и что возвращено?
Но если это так, то мне придется увеличивать сложность тестов и писать одно и тоже в геометрической прогрессии. Или же не нужно проверять внутреннею работу других объектов?

Расскажите как правильно, а то очень сложно самому догадаться.

Answer 1

[Сергей Протько]

Есть непонимание процесса написания правильных тестов.

Процесс просто. Формализуем тест кейс, описываем его в виде теста. Причем нужно делать так, что бы тесты ничего не знал о реализации нашего объекта, завязка исключительно на интерфейс. Тогда оверхэда на написание и поддерживание тестов практически не будет.

Добавил я продукт и что мне мониторить?

У вашего объекта должен быть какой-то публичый метод, который может предоставить проверку.

Если такого метода нет, то нам надо подменить List на мок, но ваш код этого не позволяет сделать. Опять же это мы уже тест на реализацию завязываем, а стало быть наши тесты становятся хуже. Но коль уж мы пошли по этому пути можно просто length померять.

Comments

[copal]

По первому пункту с Вами согласен, но это относится к объекту, а у меня сложность с пониманием тестирования именно методов.
А по второму пункту Вы предлагаете агрегацию вместо композиции чтобы при инициализации фабрики подменять лист? В реальности я так и делаю и при этом для проверки метода insertProduct я бы сделал следующие -
- проверил insertProduct на возникновение исключения
- проверил что было передано в метод hasItem
- проверил что было возвращено из метода hasItem
- проверил что было передано в inserItem
- дальше бы я не стал проверять, так как на предыдущем этапе написал тест для List и удостоверился в том, что при добавлении происходит так как мне нужно
- проверил бы insertProduct на вызов с исключением

Так нужно методы тестировать? Есть что добавить убавить?
Я это спрашиваю из-за того, что очень часто я трачу на написание теста в три четыре раза больше время чем на сам код. Возможно это из-за того что я ещё не привык их писать, но так же есть мысли что я через чур их подробными делаю.
Еще есть чувство "пятой ноги" когда я написав тест для List пишу его снова уже в композиции с тестом для Factory. Затем я поменяв одно свойство в list, должен изменять все тесты которые были написаны без этого свойства. И я снова подчеркну что это именно при тестировании методов.

[Сергей Протько]

copal: вы определитесь что вы тестируете, List или Factory? В вашем сценарии вот все эти проверки не нужны, так как это уже реализация List, вы о ней ничего знать не должны. Реализация этой штуки уже и так покрыта тестами. Вы можете полностью list подменить на мок, и трекать только работу вашего метода с этим объектом.

Ну и да, не зацикливайтесь на "тестировать метод". Вы тестируете поведение, путем проверки итогового состояния. А итоговое состояние хранит уже объект.

В вашем случае я бы вообще эту штуку юнит тестами не покрывал бы, ибо она тривиальна. Вместо этого я бы добавил интеграционный тест который проверяет общую функциональность.

Если же следовать вашему сценарию - то у нас тест будет на 100% знать как устроена реализация метода. А это не очень хорошо, так как на каждый чих придется править тесты. Ну то есть баланс надо соблюдать как-то.

[Сергей Протько]

copal: пока писал, подумал.... а зачем нам вообще в этой ситуации моки? Почему бы просто не передать полноценную реализацию?

let list, factory;

beforeEach(() => {
     list = new List();
     factory = new Factory(list);
});

it ('adds product', () => {
    factory.insertProduct(product);
    expect(list.length).to.be(1);
});

it ('checks is product already added', () => {
    list.insertItem(product);
    factory.insertProduct(product);
    expect(list.length).to.be(1);
});

[copal]

Сергей Протько: ну я и подменяю экземпляр List на ListSpyObj и уже его проверяю на вызов и подмену делаю возвращаемых значений. И вот я не знаю как быть с определением тривиальности ведь в этом минимальном примере добавление и проверка и в любом другом коде будет тоже самое, ведь это программирование которое сводится к структурам данных.
ну в общем я понял... Прежде модульное тестирование, а тесты для методов уже по своему желанию. Просто я всегда хотел писать код без его выполнения. То есть полностью по тестам, ведь нет разницы, что я его с console.log буду проверять (это я про написание самой реализации поведения) что я его тестами покрою только раз, в отличии от первого, где console.log придется писать и два и три и четыре раза.

[Сергей Протько]

copal: "тестировать методы" вообще как-то не звучит. Мы покрываем тестами код метода, но тестируем мы объект (поскольку их отделить друг от друга не выйдет, только если это статический метод, представляющий собой чисту функцию).

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

[copal]

Сергей Протько: UniqueList это пререопределяющий поведение обычного листа, добавляя в него проверки?

[Сергей Протько]

copal: да, тип того. Либо декоратор поверх.

[copal]

Сергей Протько: а вы случаем не знаете в ts есть декораторы, которые из es7?

[Сергей Протько]

copal: есть.