Подсчет вызовов методов в модульных тестах

Question

Каков наилучший способ подсчета вызовов методов в модульном тесте.Позволяет ли это какой-либо инфраструктуре тестирования?

Answer 1

Похоже, вы можете использовать методы типа .expected (1), которые обычно предоставляют макеты фреймворков.

Используя mockito, если вы тестировали List и хотели убедиться, что clear вызывался 3 раза, а add вызывался хотя бы один раз с этими параметрами, выполните следующие действия:

List mock = mock(List.class);        

someCodeThatInteractsWithMock();                 

verify(mock, times(3)).clear();
verify(mock, atLeastOnce()).add(anyObject());      

(от http://code.google.com/p/mockito/wiki/MockitoVSEasyMock)

Answer 2

В Mockito вы можете сделать что-то вроде этого:

YourService serviceMock = Mockito.mock(YourService.class);

// code using YourService

// details of all invocations including methods and arguments
Collection<Invocation> invocations = Mockito.mockingDetails(serviceMock).getInvocations();
// just a number of calls of any mock's methods
int numberOfCalls = invocations.size();

Answer 3

Вы можете посчитать количество вызовов методов, используя интерфейс Answer in Mockito.

ConnectionPool mockedConnectionPool = mock(ConnectionPool.class);

    final int[] counter = new int[1];

    when(mockedConnectionPool.getConnection()).then(new Answer<Connection>() {

        @Override
        public Connection answer(InvocationOnMock invocation) throws Throwable {
            counter[0]++;
            return conn;
        }

    }); 
    // some your code

    assertTrue(counter[0] == 1);

Answer 4

В качестве примера приведен пример класса «RoleRepository» с единственным методом «getRole (String user)», который возвращает роль.

Предполагается, что вы объявили этот объект как Mock или Spy и хотите проверить, является ли объектметод getRole (String) вызывается один раз.

Вы бы сделали что-то вроде: Mockito.verify(roleRepository, Mockito.times(1)).getRole(Mockito.anyString());

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mockito;
import org.mockito.Spy;
import org.mockito.junit.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class RoleRepositoryTest {

    @Spy
    private RoleRepository roleRepository = new RoleRepository();

    @Test
    public void test() {
        roleRepository.getRole("toto");
        Mockito.verify(roleRepository, Mockito.times(1)).getRole(Mockito.anyString());
    }

    public static class RoleRepository {

        public String getRole(String user) {
            return "MyRole";
        }
    }
}

Answer 5

В зависимости от того, какие методы вы хотите сосчитать, вы можете создать тестовую конфигурацию с советом @Before, соответствующим вашему классу / пакету / методу:

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class MethodCounterAspect {

    private int counter = 0 // or inject the Counter object into this aspect

    @Pointcut( "execution( * com.sample.your.package.*.*(..) )" )
    public void methodsToCount() {}

    @Before("methodsToCount()")
    public void execute() throws Throwable {
        counter++; // or update the counter injected into this aspect..
    }

    // get the counter
}

Вы можете использовать vanilla AspectJ или Spring AOPчерез выше или конфиги XML, если вам проще.

Вы можете создавать различные точки / аспект, если вам нужно.

Answer 6

Звучит так, как будто вам нужен тестовый шпион .См., Например, Mockito.spy () .

Answer 7

У вас есть несколько вариантов

1) Добавьте специальный код, который подсчитывает количество вызовов в функции.Это будет работать, но это не очень хорошее решение.

2) После запуска модульных тестов проверьте покрытие кода.Большинство инструментов покрытия считают счета, но они действительно предназначены для последующей обработки.

3) Используйте профилировщик.Профилировщик позволит вам подсчитать, сколько раз вызывается функция.Это очень ручной процесс, поэтому он не предназначен для модульного тестирования.

Лучшим решением было бы проверить, что вы ожидаете, а не проверить, как он работает внутри.