Может ли юнит-тест метода класса зависеть также от других методов?

Question

[Никита]

Если кратко - то весь вопрос в сабже.
Если более подробно - я в тестировании новичёк, пишу первые в своей жизни тесты (с помощью Google Test Framework) для класса двусвязного списка.
Нужно протестировать, скажем, метод pop_back (удалить последний элемент списка). Но если не использовать другие методы класса, то для того, чтоб хоть как-нибудь наполнить этот список, придётся писать в тесте низкоуровневый код создания узлов, их связывания и т.п. Как быть?

Answer 1

[Дмитрий]

Один тест - одна проблема. Тест должен выявлять СТРОГО одну проблему! Как вывод: не следует делать так, чтобы один тест зависил от другого.

Мне кажется ВЫ не совсем верно понимаете что такое модульный тест. Вот его достаточно верное определение: Unit Test - Definition

Answer 2

[Mercury13]

Да, может. Всё, что я здесь пишу, — моё ИМХО, обусловленное вечной нехваткой времени и ошибками в базовых функциях (высокоуровневый код тестировать крайне сложно и я не в курсе, есть ли стандартные методы автоматизации тестирования).

Излишне сложный код тестовых функций также приходится тестировать — поэтому нет ничего зазорного в том, чтобы использовать функции, проверенные другими тестами. Собственные низкоуровневые функции стоит использовать, если они либо проще, либо заводят объект в какое-то контролируемое состояние, которого сложно достичь общедоступным интерфейсом. Таким образом, код теста должен быть примерно такой.
1. Собрать нужный нам список.
2. Проверить, что список в нужном нам состоянии.
3. Удалить один элемент.
4. Проверить, что новое состояние правильное.

В пунктах 2 и 4 проверок может быть много — например, в пункте 2 «список корректно связан, в нём 3 элемента и два последних Б, В», в пункте 4 — «список корректно связан, в нём 2 элемента и последний Б». Главное, чтобы а) проверялась одна концепция — например, «работает удаление с конца»; и б) все концепции, которые нужны для корректной работы теста — например, «конструируется пустой список», «добавить в пустой» и «добавить в конец» — тоже надо проверить.

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

Comments

[Oxoron]

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

[Mercury13]

Спасибо, что напомнил — «конструируется пустой список» тоже концепция.

Answer 3

[slvABTOP]

Не может зависеть. Писать низкоуровневый код

Answer 4

[Никита]

Мнения рознятся. Значит ли это, что однозначного ответа на мой вопрос нет?

Comments

[Mercury13]

Ещё пара аргументов в мою пользу.
1. Юнит-тесты — дело и без того муторное, зачем делать сложнее?
2. Вот такой код прошёл ревизию в киевском ШАДе (комментарии не входили в код, вписал специально для тебя).

@Test
    public void testIterator_hasPrev() {
// Подготовка состояния
        Integer[] items = { 1212, 3434, 5656 };
        MyArrayList<Integer> list = new MyArrayList();
        list.addAll(items);
        ListIterator<Integer> it = list.iterator();
        while(it.hasNext()) {
            it.next();
        }
// Работа-проверка. Проверяем мы итератор, потому дело чуть посложнее, чем проверить удаление
        assertTrue("hasPrev() №0", it.hasPrevious());
        it.previous();
        assertTrue("hasPrev() №1", it.hasPrevious());
        it.previous();
        assertTrue("hasPrev() №2", it.hasPrevious());
        it.previous();
        assertFalse("hasPrev() №-1", it.hasPrevious());
        try {
            it.previous();
            fail("next() №3 — нужна авария!");
        } catch (IllegalStateException ex) {
        }
    }

С моей теперешней колокольни, я бы просто сделал две тестовые функции: getListOf(new Integer(){11, 22, 33}) и windIteratorToEnd(). Ведь это не единственный тест, за ним идёт батарея таких же. А остальное — оставил бы как есть.

[Mercury13]

Аргумент №3. Мы привязываемся к особенностям внутренней реализации списка, и небольшая переделка модуля приведёт к изменению всех тестов. Зачем?

Аргумент №4. Это тест самого jUnit.

public void testFailure() {
        String expected = expected(new String[]{".F", "Time: 0", "Failures here", "", "FAILURES!!!", "Tests run: 1,  Failures: 1,  Errors: 0", ""});
        ResultPrinter printer = new TestResultPrinter(new PrintStream(output)) {
            @Override
            public void printFailures(TestResult result) {
                getWriter().println("Failures here");
            }
        };
        runner.setPrinter(printer);
        TestSuite suite = new TestSuite();
        suite.addTest(new TestCase() {
            @Override
            public void runTest() {
                throw new AssertionFailedError();
            }
        });
        runner.doRun(suite);
        assertEquals(expected, output.toString());
    }

[Mercury13]

И вообще в jUnit нет залезания грязными руками во внутренности объекта.

Answer 5

[immortal-true]

Ну вообще согласно определения Юнит-тестирования, один тест тестирует один метод. Если тесту требуются какие-то вводные данные, то вы подсовываете ему "болванку". Так что сценарий теста будет скорее такой:
1. Создать (хардкодом) список.
2. Удалить элемент (с помощью тестируемого метода).
3. Проверить, что элемент удален.