Mockito Passes, но код покрытия по-прежнему низкий

package com.fitaxis.test; 

import java.sql.SQLException; 

import org.junit.Assert; 
import org.junit.Test; 
import org.mockito.Mockito; 
import org.mockito.invocation.InvocationOnMock; 
import org.mockito.stubbing.Answer; 

import static org.mockito.Mockito.*; 

import com.fitaxis.leaderboard.LeaderBoard; 

public class LeaderBoardTests { 


@Test 
public void TestThatDataIsSavedToTheDatabase() 
{ 
    LeaderBoard leaderBoard = mock(LeaderBoard.class); 
    //doNothing().doThrow(new RuntimeException()).when(leaderBoard).saveData(); 

    when(leaderBoard.saveData()).thenReturn(true); 

    boolean res = leaderBoard.saveData(); 

    verify(leaderBoard).saveData(); 

    Assert.assertTrue(res); 
} 

}

Я использовал mockito для издевательства над классом, но когда я использую покрытие кода, он не обнаруживает, что вызванный метод. Я делаю что-то неправильно? Пожалуйста помоги!Mockito Passes, но код покрытия по-прежнему низкий

источник

2010-09-11 ferronrsmith

Не понимаю вопроса. Вызывается ли исключение? Что значит «охват кода по-прежнему низкий» - вы проверяете с помощью внешнего инструмента? Который из них? Cobertura? – Bozho

Я использовал EclEmma. Обычно, когда я издеваюсь над материалом и использую такой инструмент, как NCover, он показывает метод, который вызывается, мне интересно, не делаю ли я что-то неправильно, это все. – ferronrsmith

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

Другими словами, ваш тест говорит:

Когда я называю saveData(), фальсифицировать результат, чтобы вернуть истинный
Позовите saveData() - яй, результат был правдой!

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

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

Вы должны , вероятно, издеваться над зависимостями от Leaderboard, а не от Leaderboard. Если вы должны издеваться из saveData(), вы должны испытывать методы, вызовsaveData() ... проверить, что они сохраняют правильные данные, что они действуют правильно, когда saveData() возвращает ложь, и т.д.

источник

2010-09-11 06:24:32

Правильно, но я сделал то же самое с NUnit и RhinoMocks, и NCover обнаружил это как звонок. Мне интересно, должен ли я использовать интерфейс вздоха. – ferronrsmith

Кажется, мне нужно сделать интеграционный тест, я пытался избежать попадания в БД для теста, но макет сохранял его в БД, но похоже, что мне нужно получить код. Спасибо за помощь всем :) – ferronrsmith

@ferronrsmith: Кажется, у вас пропало желание моего сообщения: ** ваш тест бессмыслен **. Это не тестирование * любого * вашего кода. Что вы ожидали от этого? Вы не должны писать тесты для получения кода; вы должны писать их, чтобы использовать свой код. Тестирование, которое вы представили, не делает этого. Во что бы то ни стало отмахивается часть сохранения, но затем вызывайте другой код, который в свою очередь вызывает 'saveData()'. Просто вызов 'saveData()' напрямую бессмысленен. (Я интриг о том, как вы использовали NUnit и RhinoMocks, когда это код Java, кстати ... Очевидно, вы не тестировали один и тот же код.) –

, если я понимаю, ваше вопрос правильно:

потому что вы издеваетесь над Лидербордом. это означает, что вы его не тестируете.

Если вы хотите протестировать LeaderBoard, вы должны проверить фактический класс, а не на насмешку.

Предположим, вы хотите протестировать класс A, но этот класс зависит от B и B, что немного сложно создать в тестовой среде (по какой-либо причине). в таких случаях вы можете высмеять B.

, но вот ваш случай, когда вы издеваетесь над классом A. это означает, что вы ничего не тестируете.

источник

2010-09-11 06:24:50 mhshams

Mockito Passes, но код покрытия по-прежнему низкий

ответ

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