2015-09-16 3 views
0

Я унаследовал старый проект Java 1.5, который использует EJBs 3.0 и не имеет тестов.Как отключить тестирование устаревшего приложения, которое злоупотребляет статическим?

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

public final class EJBHelper { 

    private static InitialContext context; 

    static { 
     try { 
      context = new InitialContext(); 
     } catch (NamingException e) { 
      ... 
     } 
    } 

    public static Object getBean(String entity) throws NamingException { 
     return context.lookup("PROJECT_EAR/" + entity + "Bean/local"); 
    } 
} 

В каждом классе этот код повторяется для каждого EJB боба, что необходимо:

public class SomeService { 
    private static SomeBean someBean; 
    private static SomeBean getSomeBean() throws NamingException { 
     if (someBean== null) { 
      someBean= (SomeBean) EJBHelper.getBean("some"); 
     } 
     return someBean; 
    } 

    private static AnotherBean anotherBean; 
    private static AnotherBean getAnotherBean() throws NamingException { 
     if (anotherBean == null) { 
      anotherBean= (AnotherBean) EJBHelper.getBean("another"); 
     } 
     return anotherBean; 
    } 

    public doSomething() { 
     getSomeBean().findAll(...) 

     getAnotherBean().makePersistent(...) 
    }  
} 

Как я должен реорганизовать этот беспорядок ?

ответ

0

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

+0

Я все еще расследую. Я думал создать несколько фабрик, чтобы объединить эти вызовы. – KirdApe

+0

Извините за поздний ответ. Я думаю, что ключ состоит в том, чтобы реорганизовать статические классы в классы экземпляров, которые реализуют интерфейсы, а затем использовать эти интерфейсы по всему классу, чтобы вы могли заглушить/макет и т. Д. Если вам абсолютно необходимы статические классы, возможно (I ' вы никогда не пробовали это), но уродливое обходное решение может заключаться в том, чтобы выявить способ в вашем статическом классе, чтобы вы могли вводить ваши поддельные методы, чтобы вы могли в основном заглушить поведение ваших статических методов в своих модульных тестах. –

+0

Спасибо за ответ @WilWang Я думаю, что уродливое обходное решение, которое вы описываете, является самым безопасным решением. – KirdApe

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

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