2013-05-03 2 views
0

Я новичок в модульном тестирование и Mockito, но мне нужно, чтобы проверить этот класс:Mockito Метод испытание аннулируется, переменная член переопределения

public class XMLHandler { 
    private static final String CONFIG_FILE = "path/to/xml"; 
    private XMLConfiguration config = null; 

    public XMLHandler() { 
     try { 
      config = new XMLConfiguration(CONFIG_FILE); 
      config.setValidating(true); 
     } catch (ConfigurationException e) { 
      LOGGER.log(Level.SEVERE, e); 
     } 
    } 

    public List<ConfigENtries> getEntries() {  
     // do some stuff 
     return list; 
    } 

    @Override 
    public void removeEntry(int index) { 
     // remove entry 
    } 
} 

Я думаю, что я должен переопределить переменные конфигурации с макетом, но я у меня нет сеттера, так как я могу это сделать? А как насчет removeEntry? Как проверить метод void?

Я надеюсь, что кто-то может помочь мне с этим

+0

Возможный дубликат [http://stackoverflow.com/questions/15406769/how-to-mock-objects-that-are-not-passed-as-arguments](http://stackoverflow.com/questions/15406769/ как-к-mock-objects-that-are-not-pass-as-arguments) –

+0

Вы можете изменить класс? –

+0

С помощью частного конструктора вы не сможете проверить это в другом классе. –

ответ

1

Как вам разрешено изменять свой класс, я бы предложил следующую структуру:

public class XMLHandler { 
    private final XMLConfiguration config; 

    public XMLHandler(XMLConfiguration config) { 
    this.config = config; 
    } 

    public List<ConfigENtries> getEntries() {  
    // do some stuff 
    return list; 
    } 

    @Override 
    public void removeEntry(int index) { 
    // remove entry 
    } 
} 

Убедитесь, что XMLConfiguration является интерфейс, не конкретная реализация. Затем вы можете высмеять параметр config, переданный вашему конструктору. (Примечания: вы можете издеваться неконечным класс бетона тоже, но с помощью интерфейса, было бы предпочтительнее.)

Вы можете проверить публичные методы XMLHandler и подтвердить правильное поведение, проверяя призывы к config и утверждению ответы метода верны.

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

+0

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

+0

@ChrisKnight Да, хороший момент. Я должен был это ясно понять. Я отредактировал соответственно. –

0

Хотя я бы предпочел также модифицировать конструктор и передать XMLConfiguration как предполагает @DuncanJones (или какой-то другой вид Dependency Injection), вы можете использовать Mockito издеваться XMLConfiguration с помощью @InjectMocks аннотацию в тесте:

@RunWith(MockitoJUnitRunner.class) 
public class XMLHandlerTest { 

    @InjectMocks 
    XMLHandler handler = new XMLHandler(); 

    @Mock 
    XMLConfiguration config; 

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