LINUX.ORG.RU
Новости — Документация  

Grester облегчает JUnit-тестирование Java-приложений

 , , ,


0

0

Вы написали пакет unit-тестов. Как программисту, вам приходится выполнять свои тесты по много раз в день, особенно в среде непрерывной интеграции. Но что будет с тестами, если нужно изменить исходные коды? Ответ на этот вопрос легко получить, объединив возможности Jester и Maven в Grester.В этой статье мы не будем вдаваться в технические детали интерпретации выходных данных Jester и приводить подробное описание его работы. Здесь приводятся рекомендации по приобретению и использованию Maven-модуля, выступающего оболочкой для Jester.

>>> Подробности

★★★

Проверено: Shaman007 ()
← Psi 0.13
Найдена серьезная уязвимость в Bind 9 →
 ← 1 2

мм, новая статья от ибма, надо почитать...

TERRANZ ★★★★
()

"работает J2EE-консультантом в серверной Вирджинии." (c)

Доставило немеренно.

Bioreactor ★★★★★
() 

Посмотрел статью... Какой же Junit многословный...
>public class CommandExecutorTest extends TestCase

В C# все как-то короче, не по вижулбейсиковски...
>[Test]public void CommandExecutorTest()

:)

impfp ★
()
Ответ на: комментарий от k0l0b0k

>а что, правду говорят что сегодня будет срач Java vs C#? бежать за попкорном?

Такой срач бесперспективен, пока в нем не появится индивид, который заявит, что Java и С# гавно, а плюсы рулят.

zloelamo ★★★★
()
Ответ на: комментарий от zloelamo

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

val-amart ★★★★★
()
Ответ на: комментарий от k0l0b0k

>как-то уныло и толсто. не то.

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

zloelamo ★★★★
()
Ответ на: комментарий от impfp

>В C# все как-то короче, не по вижулбейсиковски... >>[Test]public void CommandExecutorTest()

Толсто! В JUnit можно и так:

@Test public void CommandExecutorTest()

Где разница? И сильно оно лучше чем прото наследование? Какя вообще разница? Жава, сишарп, одна хрень. Хаскель рулит!

dizza ★★★★★
()
Ответ на: комментарий от impfp

> Посмотрел статью... Какой же Junit многословный...

пример был просто для старого джиюнита, в 4ой версии все точно также и даже на 1 символ короче :) "@Test"

RomanIvanov
()

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

Droid790 ★
()
Ответ на: комментарий от zloelamo

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

ммм.... наверное наоборот?

k0l0b0k ★★
()
Ответ на: комментарий от k0l0b0k

>ммм.... наверное наоборот?

Тогда было бы не уныло. Наоборот только в Gnome vs KDE. Там даже закоренелый троль становится дебилом.

zloelamo ★★★★
()
Ответ на: комментарий от nexus86

> ну и чем вам С# не нравится?кроме того что он от МС

велосипеды и квадроциклы на каждом шагу. нарушение принципов ООП.

slyjoe
()
Ответ на: комментарий от Droid790

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


или толсо, или поймёте - когда будете делать большие модификации в сложной программе, да ещё работающей в продакшене, да ещё разрабатываемую не тобой а многими девелоперами фирмами.
(хинт: посылать всё тестерам на регрессионный тест на каждый чих - замучаешься, или будешь девелопить годами или с бесконечным бюджетом).

Я например вписываю кучу запросов в базу на контрольные суммы правильных результатов - и даже после больших изменений, без тестов могу засылать код в продакшен (потому что знаю что ничего не сломал: уж если даже суммы совпадают - значит всё осталось как раньше, до изменений).

siberean ★
()
Ответ на: комментарий от impfp

> слив рискует засчитаться :)

да просто ща нет особого желания строчить что-то вменяемое)))

slyjoe
()
Ответ на: комментарий от siberean

потом всё равно - девелопишь , т.е. тестируешь сразу - что наваял. Так тестируешь сразу в юнит тесте. Там и оставляешь. Я бы сказал - что оверхеда никакого (до юнит тестов я и так писал main везде, либо main под ifndef и передача имени нужного унит-теста через -D и шелл-скрипт, проходящий через все унит-тесты. Автоматизировать работу надо, зачем компутер то?

siberean ★
()
Ответ на: комментарий от emperor

> А можно поподробнее про тестирование и тесты?

Ну конечно! Вот с этого и надо было начинать! Вот: http://www.junit.org

slyjoe
()
Ответ на: комментарий от emperor

литературы полно, влом.

Кратко - каждый тест это как main. В него кладём одну функцию, которую тестируем. Это унит-тест этой конкретной функции. Всё равно это делаете - когда пишете функцию в первый раз. Программа растёт и батч унит-тестов растёт. (то что можно написать на JUnit - можно написать на шеллах или перле или чём угодно).

Потом достаточно запустить все тесты - как один батч - и за минуты проверить - ничего-ли не сломано. Сразу видно. При продуманных тестах - тестеров, брякающих по всем клавишам, - можно увольнять (прога сама себя проверяет). Регрессионный тест называется.

siberean ★
()
Ответ на: комментарий от Droid790

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

Целиком с Вами солидарен. В свое время я тоже в хэллоуворлдах без юнит-тестов обходился прекрасно.

slyjoe
()
Ответ на: комментарий от impfp

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

>Ты судя по всему видишь только две градации — ПТУ или нобелевские лауреаты, своего рода дальтонизм

Плюсую.

Karapuz ★★★★★
()
Ответ на: комментарий от slyjoe

Я бы сделал или побайтовое сравнение с файлом-эталоном, или сравнение текстов XFA - как наиболее простое. Хотя стоит придерживаться правила полной независимости тестов от окружения (в данном случае - файловой системы)

impfp ★
()
Ответ на: комментарий от slyjoe

>Кстати, а как unit тестами проверить, правильно ли генерится pdf'ка какая-нибуть?

А как юнит тестами проверить, правильно ли Oracle сохраняет инсерты в базу? pdf-ки генерятся библиотеками, они (библиотеки) и должны уже быть проверифицированы вдоль и поперек.

Karapuz ★★★★★
()
Ответ на: комментарий от impfp

> Посмотрел статью... Какой же Junit многословный... > public class CommandExecutorTest extends TestCase

Уже давно ничего экстендить не надо. Видимо, статья - боян (по ссылке не ходил).

Bohtvaroh ★★★★
()
Ответ на: комментарий от Karapuz

>А как юнит тестами проверить, правильно ли Oracle сохраняет инсерты в базу?

Я написал библиотечку где передаю димамический SQL и тесты выглядят примерно вот так (сотни тестов, много сотен), и не только скаляры, а также и листы и хеши, откуда я просто могу вытащить что надо и сделать нужный ассерт (это упрощённо, запросы могут быть по странице длинной):

//should be exaclty 1 record
assertTrue("20".equals(
DBUtil.getScalar(
"select xxx from " +
Config.getDBSchema() + "yyy " +
"where file_submission_id=" + submissionId)));

assertTrue(DBUtil.insert("some insert"));

assertTrue("1".equals(
DBUtil.getScalar(
"some JOIN bla-bla-bla "+
" and something = 2000'" +
" and reporting='Q2'" +
" and report_status_type_code='20'" +
" and bla_submitter='1120'" +
" group by bla-bla-bla )));

assertTrue(1==DBUtil("update bla-bla-bla"));

//exactly 155 records been inserted into
assertTrue("155".equals(
DBUtil.getScalar(
"select count(*) from " +
Config.getDBSchema() + "bla_bla_and_so_on ")));

siberean ★
()
Ответ на: комментарий от Karapuz

> А как юнит тестами проверить, правильно ли Oracle сохраняет инсерты в базу? pdf-ки генерятся библиотеками, они (библиотеки) и должны уже быть проверифицированы вдоль и поперек.

Библиотеки проверифицированы. Вопрос в другом. К примеру, некая система раз в 2 часа шмонает все устройства в сети, затем генерит pdf страниц на пицот. И, допустим, какая-то одна табличка почему-то съехала вправо на пиксель. Как такое unit тестом проверить?

slyjoe
()
Ответ на: комментарий от slyjoe

>Кстати, а как unit тестами проверить, правильно ли генерится pdf'ка какая-нибуть?

я бы подёргал пдф-ку через какой-то АПИ (чтобы быть не зависимым от конкретной версии ПДФ) - на предмет наличия основных элементов. (ну грубо можно размер проверить - что не меньше чего-то, так как основная масса обломов будет - это когда ПДФда пустая или типа того). Статистически надо смотреть - что в основном ломают.

siberean ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2
← Psi 0.13
Документация
Найдена серьезная уязвимость в Bind 9 →