Тестирование модуляции Java: самый простой способ проверить, вызван ли обратный вызов

Question

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

@Test 
public void testMethod() { 
    final boolean[] passed = {false}; 
    method(new Callback() { 
     @Override 
     public void handle(boolean isSuccessful) { 
      passed[0] = isSuccessful; 
     } 
    }); 
    assertTrue(passed[0]); 
} 

Это похоже на суррогат. Я хотел бы знать: есть ли более элегантный способ протестировать такой код, чтобы сделать код выше похожим на псевдокод ниже?

@Test 
public void testMethod() { 
    // nothing explicit here, implicit boolean state provided by a test-runner 
    method(new Callback() { 
     @Override 
     public void handle(boolean isSuccessful) { 
      if (isSuccessful) { 
       pass(); // not sure how it should look like: 
         // * an inherited method that sets the state to "true" 
         // * or an object with the pass method 
         // * whatever 
         // but doesn't exit testMethod(), just sets the state 
      } 
     } 
    }); 
    // nothing explicit here too: 
    // test runner might check if the state is changed to true 
    // otherwise an AssertionError might be thrown at the end of the method implicitly 
} 

Немного чище. Возможно ли это в JUnit, TestNG или любой другой структуре тестирования? Благодаря!

---

UPDATE

К сожалению, я, кажется, задал смутный вопрос, который на самом деле не соответствует то, что я хотел спросить. Я в основном имел в виду любой код (не обязательно обратный вызов), который может быть вызван, если определенные условия удовлетворяются только до , чтобы установить состояние результата в значение. Проще говоря, я просто хочу избавиться от начального boolean[] passed и окончательного assertTrue(passed[0]), считая, что они являются своего рода прологом и эпилогом соответственно и предполагают, что начальное состояние установлено на false, поэтому необходимо вызвать pass(), чтобы установить состояние на true , Независимо от того, , какpassed[0] установлен в true, где бы ни было. Но, к сожалению, я задал этот вопрос, используя контекст обратных вызовов, однако это просто вариант, а не требование. Таким образом, название вопроса не отражает то, что я действительно хотел спросить, но перед обновлением были опубликованы некоторые ответы.

Answer 1

Это обычно то, что насмешливое фреймворк может сделать для вас.

С Mockito, например:

// imports ommited for brevity 
@Test 
public void callbackIsCalled() 
{ 
    final CallBack callBack = mock(CallBack.class); 
    method(callBack); 

    verify(callBack, only()).handle(any()); 
} 

Конечно, это пример режима проверки (only()) и значением согласовани (any()). Вы можете сделать больше ...

(существуют и другие насмешливые рамки, но я лично считаю Mockito самым простым в использовании, кроме того, что один из самых мощных)

Answer 2

Учитывая, что это своего рода вещь, которую вы «повторно, скорее всего, нужно в нескольких местах, я бы просто создать именованный класс использовать для испытаний:

public class FakeCallback implements Callback { 
    private boolean wasSuccessful; 
    private boolean handleCalled; 

    @Override public void handle(boolean isSuccessful) { 
     this.wasSuccessful = isSuccessful; 
     handleCalled = true; 
    } 

    // Getters for fields above 
} 

Вы можете использовать что-то вроде:

// Arrange... 
FakeCallback callback = new FakeCallback(); 

// Act... 
method(callback); 

// Assert 
assertTrue(callback.wasHandleCalled()); 
assertTrue(callback.wasSuccessful()); 

Вы могли бы абсолютно использовать насмешливую структуру для этого вместо этого, но лично я нахожу, что часто проще создать единую фальшивую реализацию, чем настраивать mocks повторно. Оба способа будут работать.

Answer 3

список

Дают :: добавить обратного вызова

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

List<Boolean> callbackArgs = new ArrayList<>(); 
methodUnderTest(callbackArgs::add); 
// assert that the callback was called exactly once and with a "true" value: 
assertEquals(Arrays.asList(true), callbackArgs); 

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

List<String> callbackArgs = new ArrayList<>(); 
methodUnderTest(callbackArgs::add); 
// assert that the callback was called twice with "foo" and "bar" values respectively: 
assertEquals(Arrays.asList("foo", "bar"), callbackArgs); 

Аналогично, класс счетчика может служить для тестирования обратного вызова, который не принимает никаких параметров. Здесь с помощью AtomicInteger, как кажется, только счетчик типа класса доступен в стандартных библиотеках - свойство атомарности не нужно здесь:

AtomicInteger callbackCounter = new AtomicInteger(); 
methodUnderTest(callbackCounter::incrementAndGet); 
// assert that the callback was called 5 times: 
assertEquals(5, callbackCounter.get());