2013-06-06 8 views
0

Я хочу проверить, Collection.sort(...) называется ли или нет с JMockit:гася статический метод с JMockit помощью «любой»

final List<Employee> employees = new ArrayList<>(); 
new Expectations() { 
    { 
    Collections.sort((List<Employee>) any); 
    result = employees; 
    } 
}; 

assertThat(EmployeeRepository.getAllOrderedByName()).isSameAs(employees); 

Это реализация моего примера хранилище под тест:

public class EmployeeRepository { 

    private static List<Employee> employees = new ArrayList<>(); 

    public static List<Employee> getAllOrderedByName() { 
    Collections.sort(employees); 
    return employees; 
    } 
} 

Когда я запускаю модульный тест, я получаю исключение NullPointerException в Collections.sort. Кажется, что это проблема в издевательстве, так как отладчик никогда не достигает точки останова в методе getAllOrderedByName.

Как я могу ставить статические методы, используя any с JMockit?

+0

Неужели вы возвращаете список, который вы отсортировали (который, кажется, является списком экземпляра)? – fge

+0

Нет, это была ошибка. – deamon

ответ

5

В вашем тестовом коде класс Collections не указан, чтобы быть издеваемым. Таким образом, вызов Collections.sort((List<Employee>) any); вызывает NPE, потому что значение any равно null и выполняется фактический метод sort.

Возможно, вы предположили, что любой вызов метода внутри блока ожидания будет автоматически высмеиваться, но это не, как работает JMockit API. Вместо этого вам нужно явно указать, какие типы посмеялись, объявив фальшивое поле или параметр макета, аннотированный @Mocked, @NonStrict, @Cascading, или @Capturing.

Кроме того, в этом случае Collections.sort - это метод, который возвращает void, поэтому нет смысла записывать возвращаемое значение для него.

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

1

Это не ответ на ваш конкретный вопрос (и я имел трудности с any себя в прошлом, так что я стараюсь избегать его!), Но вы можете использовать макете вместо:

final AtomicBoolean wasCalled = new AtomicBoolean(); 

new MockUp<Collections>() { 
    @Mock 
    public <T extends Comparable<? super T>> void sort(List<T> list) { 
     wasCalled.set(true); 
     //no-op otherwise 
    } 
}; 

assertThat(EmployeeRepository.getAllOrderedByName()).isSameAs(employees); 
assertTrue(wasCalled.get()); 
1

I Wouldn» Так сделай это, если бы я был тебе.

Сначала проверьте, что ваш Comparable на Employee работает.

Затем создайте издевательства над вашим классом Employee. Примечание: с помощью Mockito здесь, но я предполагаю, что это может быть адаптирована к JMockit (который я никогда не использовал):

private static final int NR_MOCKS = 20; 

// .... 

List<Employee> sorted = new ArrayList<>(NR_MOCKS); 
for (int i = 0; i < NR_MOCKS; i++) 
    sorted.add(mock(Employee.class)); 

// Create a shuffled list of the sorted list 
List<Employee> shuffled = new ArrayList<>(sorted); 
Collections.shuffe(shuffled); 

// Inject shuffled into repository 

// Stubs 
for (int i1 = 0; i1 < NR_MOCKS; i1++) 
    for (int i2 = 0; i2 < NR_MOCKS; i2++) 
     when(sorted.get(i1).compareTo(sorted.get(i2))).thenReturn(i2 - i1); 

List<Employee> actual = EmployeeRepository.getAllOrderedByName(); 

assertEquals(actual, sorted); 

не только проверить, что список в конечном счете, сортируется (так как вы уже проверили Comparable реализацию заранее), но вы все равно какой алгоритм сортировки; это Just Works (tm).

 Смежные вопросы

  • Нет связанных вопросов^_^