Внутреннее покрытие класса в Java - PullRequest
0 голосов
/ 29 апреля 2019

В настоящее время я работаю над написанием Junits для класса, который присутствует внутри класса, т.е. внутреннего класса.

public class MainClassJob {
    public class UserRowMapper implements RowMapper<MyReport> {
        @Override
        public MyReport mapRow(ResultSet rs, int rowNum) throws SQLException {
            MyReport r = new MyReport();
            r.setDate(rs.getDate("CS_DATE"));
            r.setFirstName(rs.getString("FNAME"));
            r.setFirstName(rs.getString("LNAME"));
            return r;
        }
    }
}

Может кто-нибудь подсказать мне, как я покрываю часть UserRowMapper как часть отчета о покрытии JUnit.

Ответы [ 3 ]

3 голосов
/ 29 апреля 2019

Другой ответ говорит вам, как технически 1002 * добраться до:

Может ли кто-нибудь подсказать мне, как я покрываю часть UserRowMapper как часть отчета о покрытии JUnit.

... просто написав тестовый пример, который каким-то образом запускает этот код.

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

Другими словами: вы должны спросить себя, как значимо проверить ваш код. Как: что должен делать этот код? Какие особые случаи существуют? Когда должны быть выданы исключения, ... и так далее.

Затем вы пишете тесты, которые охватывают все эти аспекты.

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

Значение: модульные тесты, которые не выполняют каких-либо заявлений или проверок, которые выполняются только для обеспечения 100% покрытия, такие тесты близки к бесполезным. Единственное, что они вам говорят: вы можете запустить этот код, как в модульном тесте, без всплывающих окон.

0 голосов
/ 29 апреля 2019

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

 MainClassJob mainClassJob = new MainClassJob();
  MainClassJob.UserRowMapper userRowMapper = mainClassJob.new UserRowMapper();
  userRowMapper.mapRow(mockResultSet,1)

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

0 голосов
/ 29 апреля 2019

Предположительно у вас есть фабричный метод для создания UserRowMapper:

private MainClassJob job;

@BeforeEach
public void before() {
    job = new MainClassJob(...);
}

@Test
public void mapRow() {
    final UserRowMapper mapper = job.mapper();
    final MyReport report = mapper.mapRow(...);
    // verify the results...
}

Если нет, то создайте экземпляр, используя job.new UserRowMapper(), хотя заводской подход более понятен и интуитивен.

Тем не менее, если средство отображения строк не использует никаких функций или членов из родительского класса (как в вашем примере), почему это не static?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...