Статьи

Соглашения об именовании модульных тестов

Декабрь 19, 2018

Существует определенное количество соглашений об именах, используемых для модульных тестов. В начале, с JUnit 3, для определения теста было обязательно, чтобы имя класса было названо как MyClassTest, начиная с TestCase, и все имена методов теста начинались с ‘test’, как в ‘testMyMethod ()’. Я думаю, что это хороший пример соглашения о конфигурации.
В JUnit 4 (или TestNG) это больше не является обязательным, и разработчик может самостоятельно определять свое соглашение об именах. Но затем вы «настраиваете» метод как тест, используя аннотацию @Test.

Существует соглашение об именах, определенное BDD, которое говорит, что класс теста и методы теста должны описывать поведение, которое вы хотите проверить.

Примеры:

имея методы испытаний, начинающиеся с

public class WhenWindowControlCloseWindow {

    @Test
    public void shouldCloseWindows() {
         //...
    }
}

Или как в этом примере (из Википедии ), который также использует комментарии для описания теста: дано / когда / тогда:

public class WindowControlBehavior {
    @Test
    public void shouldCloseWindows() {

        // Given
        WindowControl control = new WindowControl("My AFrame");
        AFrame frame = new AFrame();

        // When
        control.closeWindow();

        // Then
        ensureThat(!frame.isShowing());
    }
}

или другое соглашение, которое я видел:

public class WindowControlShould {
    @Test
    public void closeWindows() {
       //...
    }
}

Проблема здесь в том, что у вас есть 3 элемента в тесте: субъект «субъекта» теста (обычно имя класса), условие («при ​​вызове некоторого метода с некоторыми конкретными параметрами) и ожидаемый результат, который, как мы видел в BDD с именем метода « следует делать». Так что проблема в том, что с именем класса и именем метода у нас есть только два элемента для описания нашего теста.
Чтобы выразить 3-ю «сущность» фразы, я попытался использовать внутренние классы для определения таких тестов:

public class WindowControl
    public static class WhenCloseWindow {
        @Test
        public void shouldCloseWindows() {
            //...
        }
    }
}

Но это не поддерживается JUnit4.

Я думал, что пакеты могут помочь, например, указав их как

package com.mycompany.blah.blah.windowcontrol;
public static class WhenCloseWindow {
    @Test
    public void shouldCloseWindows() {
        //...
    }
}

Но таким образом вы теряете возможность вызывать стандартные и упаковывать доступные методы, что мне очень нравится в моих тестах.

Теперь я чувствую, что сначала методы испытаний были определены соглашением об именах. Затем с аннотацией, соглашение оставлено на усмотрение разработчика, или даже на выбор вообще не иметь соглашения. Для меня аннотация ближе к конфигурации, которая заменяет соглашение; своего рода контр-тенденция в тенденции соглашения по конфигурации конфигурации. Так что, если мы начнем вызывать наш тестовый метод, следует ли Something () не вернуться к старому соглашению test Something ()?
Ну, мне понравились соглашения, использованные в JUnit 3, и я не вижу больших улучшений в использовании аннотаций или свободе от расширения класса TestCase, который предоставлял assert* методы: с помощью JUnit4 мы должны статически импортировать эти методы из класса Assert; Я не вижу в этом улучшения.
Мой вкус таков: если мы не можем легко найти описательное соглашение о присвоении имен для того, что мы тестируем, лучше всего полагаться на некоторые комментарии. В приведенном выше примере, взятом из Википедии, фактически используется соглашение об именах и некоторые комментарии в коде. Я думаю, что использование комментария поверх метода лучше послужило бы описанию теста.

Наконец, некоторые инструменты непрерывной интеграции могут форматировать имена тестов (класс + метод), чтобы показать предложение, описывающее тест, красиво на естественном английском языке.
Это круто, но поскольку у нас уже есть аннотация @Test для настройки теста, почему бы не иметь описательный атрибут, который можно использовать из инструментов отчетности, таких как:

@Test(description="when WindowController.closeWindow() is invoked the window is closed")
public void testCloseWindow() {
    //...
}

Или, так как я критиковал аннотацию @Test, короткий Java-комментарий сортировал бы ту же цель для инструментов, желающих описать тест простым английским описанием.

Поскольку нет действительно хорошего соглашения об именах для тестов, так как я не вижу реальных улучшений с использованием аннотаций и статического импорта … Я думаю, что JUnit 3 работал правильно.

Что вы думаете?

От http://en.newinstance.it/2011/01/28/unit-test-naming-conventions/

61
Share: