Когда и зачем использовать Mocking при тестировании EJB - PullRequest
Новая
       16

Когда и зачем использовать Mocking при тестировании EJB

2 голосов
/ 26 ноября 2010

Как видно из моего вопроса, я не понимаю, когда и зачем использовать фиктивные объекты при тестировании ejbs.

Я использую обычный JUnit и обнаружил, что он работает со мной, но я знаю, что это не таквся история.

Пример: 

@Stateless(name = "MyService")
public class MyBean extends BaseBean implements MyService
{
    public MyBean()
    {
    }

    public List<Category> getAllMainCategories()
    {
        //Category.findAll is a named query defined in Category entity
        return (List<Category>) em.createNamedQuery("Category.findAll").getResultList();
    }
}

А вот и тестовый класс: 

public class MyServiceTest
{

    MyService service;

    @Before
    public void setUp() throws Exception
    {
        Context context = new InitialContext();
        service = (MyService) context.lookup("MyService");
    }

    @Test
    public void getAllMainCategories() throws Exception
    {
        assertNotNull(service);
        assertTrue(service.getAllMainCategories().size() > 0);
    }

}

Как видите, я выполняю модульное тестирование для сессионных компонентов безпотребность в фиктивных объектах ... так это полностью верно, или мне чего-то не хватает?

Ответы [ 2 ]

1 голос
/ 26 ноября 2010

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

0 голосов
/ 27 ноября 2010

Вы можете посмотреть здесь (блог Мартина Фаулера) для получения информации, связанной с Mocks.

Mock используются, когда вы хотите протестировать код, имеющий зависимость от побочных эффектов.Звонки в какую-либо сервисную библиотеку, например DAO, как предложил другой автор, являются типичным использованием.Однако использование макетов никогда не является обязательным.В случае DAO альтернативой может быть предоставление вашему протестированному классу некоторого объекта-оболочки DAO.В тестовом примере вы предоставили бы другой тип объекта-оболочки DAO, который генерирует контролируемые результаты.Этот метод, позволяющий избежать ложных срабатываний, называется «инъекцией зависимостей» и дает то же преимущество, что и имитации (на самом деле это то же самое, что использование библиотек имитаций, но сделано «вручную»).Но в некоторых случаях использование внедрения зависимостей вместо библиотеки Mocks немного неудобно (вам нужно определить некоторый объект-обертку, который вы можете получить вместо использования стандартного).

Лично я не очень люблю издеваться и стараюсь по возможности избегать их использования.Причины, по которым я им не нравлюсь, состоят в том, что они легко приводят к тестам, которые не дают ошибок при изменении поведения внешнего API, да, это настоящие модульные тесты, но слишком убедительные, на мой вкус.Другой момент заключается в том, что, используя mocks, мы склонны проверять внутреннее поведение того, что, как я считаю, должно быть черным ящиком, но Mocks также имеют отличных поклонников.

...