it-roy-ru.com

Тестовый класс с вызовом new () в Mockito

У меня есть устаревший класс, который содержит вызов new () для создания экземпляра LoginContext ():

public class TestedClass {
  public LoginContext login(String user, String password) {
    LoginContext lc = new LoginContext("login", callbackHandler);
  }
}

Я хочу протестировать этот класс, используя Mockito для макета LoginContext, так как он требует, чтобы перед созданием экземпляра были настроены средства безопасности JAAS, но я не уверен, как это сделать, не изменяя метод login () для экстернализации LoginContext. Возможно ли использовать Mockito для насмешки над классом LoginContext?

43
bwobbones

В будущем я бы порекомендовал ответ Эрана Харела (рефакторинг переноса new на фабрику, который можно поиздеваться). Но если вы не хотите изменять исходный код, используйте очень удобную и уникальную функцию: spies. Из документации :

Вы можете создавать шпионов из реальных объектов. Когда вы используете шпиона, тогда вызываются методы real (если только метод не был заглушен). 

Настоящих шпионов следует использовать осторожно и иногда, например, когда имеешь дело с устаревшим кодом.

В вашем случае вы должны написать:

TestedClass tc = spy(new TestedClass());
LoginContext lcMock = mock(LoginContext.class);
when(tc.login(anyString(), anyString())).thenReturn(lcMock);
45
Tomasz Nurkiewicz

Я полностью за решение Эрана Харела, и в случаях, когда это невозможно, предложение Томаша Нуркевича о шпионаже превосходно. Однако стоит отметить, что бывают ситуации, когда ни один из них не применим. Например. если метод login был немного "более подходящим":

public class TestedClass {
    public LoginContext login(String user, String password) {
        LoginContext lc = new LoginContext("login", callbackHandler);
        lc.doThis();
        lc.doThat();
    }
}

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

Для полноты картины стоит упомянуть третий метод - использование PowerMock для внедрения фиктивного объекта при вызове оператора new. PowerMock не серебряная пуля, хотя. Он работает, применяя манипулирование байт-кодом к классам, которые он симулирует, что может быть изворотливой практикой, если в тестируемых классах используется манипуляция или отражение байт-кода, и, по крайней мере, из моего личного опыта, это приводит к снижению производительности теста. Опять же, если нет других вариантов, единственным вариантом должен быть хороший вариант:

@RunWith(PowerMockRunner.class)
@PrepareForTest(TestedClass.class)
public class TestedClassTest {

    @Test
    public void testLogin() {
        LoginContext lcMock = mock(LoginContext.class);
        whenNew(LoginContext.class).withArguments(anyString(), anyString()).thenReturn(lcMock);
        TestedClass tc = new TestedClass();
        tc.login ("something", "something else");
        // test the login's logic
    }
}
27
Mureinik

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

public class TestedClass {
  private final LoginContextFactory loginContextFactory;

  public TestedClass(final LoginContextFactory loginContextFactory) {
    this.loginContextFactory = loginContextFactory;
  }

  public LoginContext login(String user, String password) {
    LoginContext lc = loginContextFactory.createLoginContext();
  }
}

public interface LoginContextFactory {
  public LoginContext createLoginContext();
}
21
Eran Harel
    public class TestedClass {
    public LoginContext login(String user, String password) {
        LoginContext lc = new LoginContext("login", callbackHandler);
        lc.doThis();
        lc.doThat();
    }
  }

- Тестовый класс:

    @RunWith(PowerMockRunner.class)
    @PrepareForTest(TestedClass.class)
    public class TestedClassTest {

        @Test
        public void testLogin() {
            LoginContext lcMock = mock(LoginContext.class);
            whenNew(LoginContext.class).withArguments(anyString(), anyString()).thenReturn(lcMock);
//comment: this is giving mock object ( lcMock )
            TestedClass tc = new TestedClass();
            tc.login ("something", "something else"); ///  testing this method.
            // test the login's logic
        }
    }

При вызове фактического метода tc.login ("something", "something else"); из testLogin () {- Этот LoginContext lc имеет значение null и выбрасывает NPE при вызове lc.doThis();

4
sunjavax

Не то, что я знаю, но как насчет того, чтобы сделать что-то подобное, когда вы создаете экземпляр TestedClass, который вы хотите протестировать:

TestedClass toTest = new TestedClass() {
    public LoginContext login(String user, String password) {
        //return mocked LoginContext
    }
};

Другой вариант - использовать Mockito для создания экземпляра TestedClass и позволить смоделированному экземпляру вернуть LoginContext.

2
Kaj

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

public class TestedClass {

    interface PojoFactory { Pojo getNewPojo(); }

    private final PojoFactory factory;

    /** For use in production - nothing needs to change. */
    public TestedClass() {
        this.factory = new PojoFactory() {
            @Override
            public Pojo getNewPojo() {
                return new Pojo();
            }
        };
    }

    /** For use in testing - provide a pojo factory. */
    public TestedClass(PojoFactory factory) {
        this.factory = factory;
    }

    public void doSomething() {
        Pojo pojo = this.factory.getNewPojo();
        anythingCouldHappen(pojo);
    }
}

Благодаря этому вы сможете легко проверять, подтверждать и проверять вызовы объекта Pojo:

public  void testSomething() {
    Pojo testPojo = new Pojo();
    TestedClass target = new TestedClass(new TestedClass.PojoFactory() {
                @Override
                public Pojo getNewPojo() {
                    return testPojo;
                }
            });
    target.doSomething();
    assertThat(testPojo.isLifeStillBeautiful(), is(true));
}

Единственный недостаток этого подхода может возникнуть, если TestClass имеет несколько конструкторов, которые вам придется дублировать с дополнительным параметром.

По SOLID причинам вы, вероятно, захотите вместо этого поместить интерфейс PojoFactory в класс Pojo, а также на производственную фабрику.

public class Pojo {

    interface PojoFactory { Pojo getNewPojo(); }

    public static final PojoFactory productionFactory = 
        new PojoFactory() {
            @Override 
            public Pojo getNewPojo() {
                return new Pojo();
            }
        };
1
Adam