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


Интересна Java? Кликай по ссылке и изучай!
Если тебе полезно что-то из того, чем я делюсь в своем блоге - можешь поделиться своими деньгами со мной.
с пожеланием
столько времени читатели провели на блоге - 
сейчас онлайн - 
Показаны сообщения с ярлыком JUnit хитрости. Показать все сообщения
Показаны сообщения с ярлыком JUnit хитрости. Показать все сообщения

воскресенье, 10 марта 2013 г.

JUnit хитрости: Ассертим все и сразу

Вот как часто пишут пользовательсвие ассерты.
    @Test
    public void test() {
        snake = new Snake(50, 50);

        assertHeadAntTail(50, 50, Direction.RIGHT, Direction.LEFT);
    }

    private void assertHeadAntTail(int x, int y, Direction headDirection, Direction tailDirection) {
        assertEquals(headDirection, snake.getDirection());
        assertEquals(tailDirection, snake.getTailDirection());
        assertEquals(x, snake.getHead().getX());
        assertEquals(y, snake.getHead().getY());
    }
Их недостаток в том, что если слетает первый, то мы не увидим всей картины - остальные не отработают. Этот антипаттерн юнит-тестирования называется "Заяц" - обычно чтобы не писать несколько разных тестов, мы просто подселяем к существующему тесту еще один ассерт. Кстати тут пахнет даже имя метода - assertHeadAndTail :) но проигнорим на минутку этот запах.
Можно изворачиваться так, как я это делал раньше. Но сегодня придумался другой способ, более легковестный.
    @Test
    public void test() {
        snake = new Snake(50, 50);

        assertHeadAntTail(50, 50, Direction.RIGHT, Direction.LEFT);
    }

    private void assertHeadAntTail(int x, int y, Direction headDirection, Direction tailDirection) {
        assertEquals( "[headX, headY, headDirection, tailDirection]",
                asString(x, y, headDirection, tailDirection),

                asString(snake.getHead().getX(), snake.getHead().getY(),
                        snake.getDirection(), snake.getTailDirection()));
    }

    private String asString(Object...args) {
        return Arrays.asList(args).toString();
    }
Слетает так
junit.framework.ComparisonFailure: [headX, headY, headDirection, tailDirection] 
Expected :[50, 50, RIGHT, LEFT]
Actual   :[50, 50, RIGHT, DOWN]
 at com.codenjoy.dojo.snake.model.SnakeDirectionTest.assertHeadAntTail(SnakeDirectionTest.java:72)
 at com.codenjoy.dojo.snake.model.SnakeDirectionTest.test(SnakeDirectionTest.java:36)
Меня устраивает!
Вот если бы только можно было бы находясь в методе получить список его параметров в текстовом виде, чтобы не писать вот так "[headX, headY, headDirection, tailDirection]" в каждом новом ассерте - было бы вообще идеально. Но эту головоломку остави на потом...

четверг, 28 октября 2010 г.

Junit хитрости: Пишем broken test suite generator

Только никому не говорите, но я имею дело с интеграционными тестами, которые в общей сложности запускаются 3 часа. Так случилось, что систему трогать никак нельзя, а значит разделять ее на модуля или вносить какие-то другие изменения - нельзя. Unit тестами и не пахнет. Есть сервис - его и тестируем. Все тормозит, а потому 300 тестов 3 часа. Читать дальше...

пятница, 10 сентября 2010 г.

JUnit хитрости: Объединяем stack traces

Junit несовершенен. Тот кто его использует каждый день, знает все его боки. Вот так, с мыслью "а как мне это исправить?" рождаются всевозможные идеи-экстэншены, одним из которых я сейчас поделюсь. Не так давно я писал в рубрике JUnit хитрости про Tихие asserts. Идея была в том, чтобы собрать все ошибки воедино. Так мы повысили информативность пользовательских ассертов.

В Junit runner для Ecpipse есть одна очень удобная фича. На View JUnit есть область Failure Trace. В ней отображается информация о stack trace в случае падения теста (1). Если там кликнуть дважды по какой-то строчке (2), то Eclipse отыщет файл и установит курсор в заданной строке (3).



Очень удобно! Но... Читать дальше...

среда, 23 июня 2010 г.

JUnit хитрости: Параметризированный тест

Привет. Сегодня мне пришла идея как параметризирровать тест. для справки скажу, что я использую до сих пор 3.8. На эту идею, уверен, найдется множество критиков - супер! Напомню, что раньше в рубрике "JUnit хитрости" писал про тихие ассерты и ловлю исключений.

И так есть большой и довольно сложный тест. Допустим он проверяет какую-то сложную логику в случае использования ресурса типа А. Но у нас есть еще ресурсы типа B, C, D с идентичной логикой взаимодействия с окружающим миром. Что делать? Копипастить? Нееет уж :) Читаем дальше....

JUnit хитрости: Tихие asserts

Не так давно я рассказывал как я проверяю исключительные ситуации в своем TDD. Сегодня поделюсь еще одним приемом, который я назвал "тихими ассертами" (quiet asserts). Бывает приходится писать (или выделять из теста) сложный пользовательский assert. Естественно такой assert состоит из нескольких примитивных. Но вот беда, когда слетает первый assert из этого пользовательского набора, то мы теряем возможность увидеть картину в целом. На помощь придут "тихие ассерты". Читаем дальше...

четверг, 17 июня 2010 г.

JUnit хитрости: Ловля исключений

Если ты разрабатываешь в стиле Test Driven Development, то вероятно как и я хочешь вытянуть их jUnit по максимуму. Возможно на те кейсы, что я опишу сейчас, есть спец фреймворки (если тебе об таковых известно - скинь линк, плз) - я об ниж пока не знаю.

Итак первый кейс - обработка исключительный ситуаций. Читаем дальше...