Тестирование плагинов

Тестирование плагинов #

Этот раздел описывает возможности написания интеграционных тестов.

JUnit #

Для тестирования механизмов плагинов к 1C:EDT используется библиоткеа JUnit 4, она интегрирована в среду разработки Eclipse. JUnit используется как для unit-тестирования так и для интеграционного тестирования.

JUnit — библиотека для модульного тестирования программного обеспечения на языке Java.

Принципы и подробные примеры использования можно найти в официальной Wiki JUnit.

Mockito #

Для создания mock-объектов в тестах мы используем библиотеку Mockito. Принципы и подробные примеры использования можно найти в официальной Wiki Mockito.

Инструменты для написания интеграционных тестов #

Мы реализовали удобную инфраструктуру использования тестовых проектов 1С:EDT с тестовыми данными для интеграционного тестирования плагинов.

Тестовая рабочая область #

Для использования тестовой рабочей области в тестах реализован Rule-класс TestingWorkspace. Этот класс предоставляет ряд методов для управления проектами с тестовыми данными:

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

Типичный тестовый сценарий выглядит следующим образом:

  • TestingWorkspace автоматически очищает тестовую рабочую область до начала теста,
  • Тест производит необходимую инциализацию состояния тестовой рабочей области, например разворачивает проект с тестовыми данными,
  • Тест проверяет какие-то механизмы на данном проекте,
  • TestingWorkspace автоматически очищает тестовую рабочую область после окончания теста.

Так как TestingWorkspace реализован как тестовый Rule (в терминах JUnit 4), то его можно использовать:

  • для предоставления новой тестовой рабочей области для каждого отдельного теста с помощью аннотации @Rule,
  • для предоставления единой тестовой рабочей области для всех тестов класса с помощью аннотации @ClassRule.
Нужно аккуратно использовать TestingWorkspace с аннотацией @ClassRule. Выполняемые тесты могут создавать побочные эффекты, т.к. они будут разделять одну и ту же тестовую рабочую область. Однако такой подход может быть полезен в тех случаях, когда необходимо написать большое количество тестов, которые не изменяют данные. Такой подход позволит избежать больших затрат времени на развертывание каждого отдельного теста.

Пример использования с тестовой рабочей областью на каждый тест класса

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
public class TestingWorkspaceRuleExampleTest
{
    @Rule
    public TestingWorkspace testingWorkspace = new TestingWorkspace();
 
    @Test
    public void testSomeProjectBehavior()
    {
        IProject project = testingWorkspace.setUpProject("Main", getClass());
 
        // Мы можем использовать тут проект для тестирования...
    }
 
    @Test
    public void testSomeOtherProjectBehavior()
    {
        IProject project = testingWorkspace.setUpProject("Other", getClass());
 
        // Мы можем использовать тут проект для тестирования...
    }
}

Пример использования с единой тестовой рабочей областью на все тесты класса

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public class TestingWorkspaceRuleClassExampleTest
{
    @ClassRule
    public static TestingWorkspace testingWorkspace = new TestingWorkspace();
 
    private static IProject mainProject;
    private static IProject otherProject;
 
    @BeforeClass
    public static void setUp() throws Exception
    {
       mainProject = testingWorkspace.setUpProject("Main", TestingWorkspaceRuleClassExampleTest.class);
       otherProject = testingWorkspace.setUpProject("Other", TestingWorkspaceRuleClassExampleTest.class);
    }
 
    @Test
    public void testSomeProjectBehavior()
    {
        // Мы можем использовать оба проекта тут для тестирования...
    }
 
    @Test
    public void testSomeOtherProjectBehavior()
    {
        // ... и тут
    }
}

Методы setUpProject(String, Class<?>) в Rule-классе TestingWorkspace производят поиск тестируемого проетка с передаваемым названием в ресурсной папке с названием workspace внутри бандла, который определается через передаваеый класс. Например, если передать сам класс теста как в примерах выше, то ожидается ресурсная папка с таким именем в этом же тестовом бандле. Более подробно можно прочитать в описании класса TestingWorkspace.

Внедрение зависимостей в тесты #

Для внедрения зависимостей в тесты реализованы классы-Runner’ы JUnitGuiceRunner и ParameterizedJUnitGuiceRunner, а так же правило (Rule) InjectWithGuice. Они могут быть использованы для внедрения зависимостей из описанных Guice модулей.

Пример использования JUnitGuiceRunner

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
@RunWith(JUnitGuiceRunner.class)
@GuiceModules(
    modules = { ModuleA.class, ModuleB.class, ModuleC.class },
    overrides = { TestModuleA.class })
public class Test
{
    @Inject
    private IServiceFromModuleA serviceFromModuleA;
 
    @Inject
    private IServiceFromModuleB serviceFromModuleB;
 
    @Test
    public void shouldTestSomething()
    {
        // Используем наши зависмости
        serviceFromModuleA.use();
        serviceFromModuleB.use();
    }
}

Правило InjectWithGuice может быть полезно когда в тесте хочется использовать какой-то свой Runner (т.к. JUnit 4 имеет ограничение на использование только одного Runner’а на тест).

Пример использования InjectWithGuice

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
public class Test
{
    @Rule
    public InjectWithGuice injectWithGuice = new InjectWithGuice(new ModuleA(), new ModuleB());
 
    @Inject
    private IServiceFromModuleA serviceFromModuleA;
 
    @Inject
    private IServiceFromModuleB serviceFromModuleB;
 
    @Test
    public void shouldTestSomething()
    {
        // Используем наши зависмости
        serviceFromModuleA.use();
        serviceFromModuleB.use();
    }
}

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