jUnit - Как утверждать, что унаследованные методы вызывается?

Предположим, у вас есть сторонняя библиотека , которую вы хотите расширить, просто добавив к ней удобные методы (например, вы можете вызвать унаследованный метод с параметрами по умолчанию).jUnit - Как утверждать, что унаследованные методы вызывается?

Использование jUnit/jMock, можно ли написать утверждение/mock expection, которое проверяет, что вызывается правильный унаследованный метод?

Например, что-то вроде этого:

class SomeClass extends SomeLibraryClass { 
    public String method(String code) { 
     return method(code, null, Locale.default()); 
    } 
}

Как я могу утверждать, что method вызывается?

источник

2009-05-12 TM.

Вы хотите проверить, была ли указана правильная подпись сообщения или вы пытаетесь проверить поиск сообщений как таковой? –

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

Используйте аннотацию @Override и дайте компилятору понять, действительно ли вы переопределили метод, как предполагалось? – killdash10

Вы можете сделать еще один подкласс внутри вашего модульного тестирования, что на самом деле говорит вам:

public class MyTest { 
    boolean methodCalled = false; 

    @Test 
    public void testMySubclass(){ 
      TestSomeClass testSomeClass = new TestSomeClass(); 
      // Invoke method on testSomeclass ... 
      assertTrue(methodCalled); 

    } 
    class TestSomeClass extends SomeClass{ 
     public String method(String code){ 
       methodCalled = true; 
     } 
    } 
}

источник

2009-05-12 16:53:25 krosenvold

Не будет ли это просто сказать вам, если ваш тестовый подкласс переписан методом, а не если ваш «настоящий» подкласс переписан методом? Этот тест пройдет, даже если ваш «реальный» подкласс не перезаписал метод. – killdash10

Модульное тестирование является более полезным для проверки функциональности данных методов, а не утверждать покрытие. Единичные тесты, которые больше заботятся о том, какой метод вызвали, знают больше о классах, которые они тестируют, чем они, вероятно, должны, не говоря уже, будут путать читателя.

Инструменты покрытия, такие как Cobertura или EMMA, расскажут, правильно ли вы использовали свой код.

источник

2009-05-12 17:09:43

Насколько я понимаю, проблема в том, что этот метод не имеет функций, кроме вызова родительского метода с правильной сигнатурой. –

Если метод не имеет функциональности, то почему он есть? В модульном тесте должно быть указано, что пользователь будет ожидать при вызове метода. –

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

трудно сказать без более конкретного примера, но я бы предположил, что это должен быть интеграционный тест - протестируйте весь пакет вместе, а не единичный тест. Иногда можно быть слишком мелкозернистым с модульным тестированием.

источник

2009-09-05 11:56:01

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

public class SomeClassTest 
{ 
    @Test 
    public void testMethod() 
    { 
     final String code = "test"; 

     new Expectations() 
     { 
      SomeLibraryClass mock; 

      { 
       mock.method(code, null, (Locale) any); 
      } 
     }; 

     new SomeClass().method(code); 
    } 
}

Этот тест использует API-интерфейс JMockit.

источник

2009-12-17 13:21:17

Это хорошая идея. Иногда вызывался метод из класса потомков = метод from supe не вызывался. – user810430

jUnit - Как утверждать, что унаследованные методы вызывается?

ответ

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