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

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

О, это сложно (рендеринг - как он там на самом деле покажет). Эвристика нужна. АПИ даст только наличие таблички. А что как нарисовалось - здесь OCR нагромождать не будешь :)

тем более на пиксель...

Графика любая плохо проверяется. Вот с текстом, парсингом - нет проблем. Поэтому мы - за символьные вычисления и картинки - от лукавого ;)

факт, что слизан, известный.

Юниттесты на данный и ему подобные вопросы не отвечают.  Тесты работаю больше как индикаторы корректности.

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

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

Юнит тесты ≠ Функциональные тесты.

Юнит тест может проверить, что некий класс делает верную последовательность вызовов библиотеки создания PDF в ответ на некоторые данные. Или что этот класс выдаёт правильный XSL-FO в ответ на некоторые данные.

Впрочем, функциональные тесты тоже можно на xxxUnit писать.

>для этого заходите http://www.old-mac.narod.ru

там обитают пожилые typicalmacuser.jpg? нафик-нафик

Тролололололо! На башорг!

У пионЭров комплекс перед хорошо оплачиваемыми Джава enterpriZe программистами?

С# - это и есть Выжуалбасик. Для работы в мелкомягкой среде. В командной строке шарпей сливает Джава-фреймворкам.

В первом случае - нормальное описание. Причем не зависящее от конкретной реализации.

Во втором жесткая привязка к мелкософтовской типа тест-тулзе.

Это хорошо, что "пережиток". Меньше пионЭров-кульхацкеров будет у корпоративной кормушки ошиваться.

Мне больше достанется.

"Regression testing"? What's that? If it compiles, it is good, if it boots up it is perfect.

(c) Linus Torvalds

>Но что будет с тестами, если нужно изменить исходные коды?

я на этой фразе сломался. Объясните плз популярным языком, что такой Grester и зачем он может понадобиться?

>В командной строке шарпей сливает Джава-фреймворкам. 
К подобным веществам, вызывающим такие сентенции, отношусь брезгливо, уж извините :)

>Во втором жесткая привязка к мелкософтовской типа тест-тулзе.
лицензия там все же zlib-like

И к вопросу об аннотациях для юнит-тестов
junit 4 вышел в 2006 году
nunit 2 вышел в 2002 году
Вам не кажется, что аннотации были-таки зело идеей, да токмо к java 4 года пиж..прикручиваемой? :)

Луговского на вас нет.

>>В командной строке шарпей сливает Джава-фреймворкам.

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

Ну, это Вы-таки меня, старика, извините.

----------------------------------------

Однажды вечером Мастер Фу и Ньюби посетили собрание программистов, которые встретились, чтобы поучиться друг у друга. Один из программистов спросил у Ньюби, к какой школе принадлежит он и его учитель. Когда Ньюби сказал, что он и его учитель - последователи Великого Пути UNIX, программист презрительно усмехнулся. "Средства командной строки Unix грубые и отсталые, - насмешливо сказал он. - Современные, правильно спроектированные операционные системы делают все через графический интерфейс пользователя". Мастер Фу не проронил ни слова, но указал на Луну. Находившийся поблизости пес залаял на руку учителя. "Я не понимаю вас", - сказал программист. Мастер Фу молчал и показал на образ Будды. Потом указал на окно. "Что вы хотите этим сказать?" - спросил программист. Мастер Фу указал на голову программиста. Потом указал на камень. "Почему вы не можете сказать яснее?" - потребовал программист. Мастер Фу задумчиво нахмурился, дважды щелкнул программиста по носу и бросил его в находящийся рядом мусорный контейнер. Пока программист пытался выбраться из горы мусора, пес ходил рядом и лаял на него В этот момент программист достиг просветления.

-----------------------------------------------

(с)

>Юнит тест может проверить, что некий класс делает верную последовательность вызовов библиотеки создания PDF в ответ на некоторые данные.

Говнянейший метод. Бессмысленный. Проверять надо результат, а не метод его достижения. По сути если ты в состоянии написать корректно проверку метода достижения рещультата - то еще проще написать его прямо в коде правильно. Иначе это бессмысленно - тест тот же код котьорый можно написать неверно. И если он сложен с точностью до повторения кода - в нем нет смысла.

там поток сознания двух людей - писателя и переводчика.

>Говнянейший метод. Бессмысленный. Проверять надо результат, а не метод его достижения.

Последовательность внешних вызовов, возвращенное значение — это и есть результат.

К примеру, есть код, который должен отправить письмо, если возникает условие X.

В коде будет написана некоторая логика и отправка письма при возникновении X.

В тесте будет создано условие X и проверено, что метод отправки письма был вызван (и что он не будет вызван во всех остальных случаях).

Вот что имелось ввиду.

>По сути если ты в состоянии написать корректно проверку метода достижения рещультата - то еще проще написать его прямо в коде правильно.

Так и не надо писать проверку метода достижения результата.

>Иначе это бессмысленно - тест тот же код котьорый можно написать неверно. И если он сложен с точностью до повторения кода - в нем нет смысла.

Функциональный код и код теста ортогональны. В одном написаны серия конкретных утверждений A->B, в другом правила вывода B из любого A.

Естественно, тест можно написать неверно. При этом тест должен быть написан так, чтобы вероятность наличия компенсирующих ошибок в коде и тесте была минимальна.

P.S. Пример с PDF действительно был очень плохой.

>...должен быть написан так, чтобы вероятность ... была...
Прикольно

Нормальный.
Подходы к проверке на смещение предложены были. Дальше пошло пустословие на тему "тест не ответит на вопрос 'почему'"

>Вот что имелось ввиду.

Я знаю что имелось ввиду. Автоматизированный тесь должен иметь сложность < сложности кода. Потому что тест - тоже код. Суть автоматизированного тестирования в 1- стабилизации функции определенного кода и 2 - выявлении ошибок. Смысл такого теста обратно пропорционален сложности. Чем более сложен тест - тем меньше в нем смысла. Вероятность ишибиться в тесте такая же как в коде. Если можешь написать сложный тест правильно - напиши лучше правильно сложный код.

>В тесте будет создано условие X и проверено, что метод отправки письма был вызван (и что он не будет вызван во всех остальных случаях).

Когда возникает такая проблема - помогает генерализация проверяемой функциии, или повышение абстракции теста - запусти сервер и проверь что письмо отправлено.

Если ты мокаешь интерфейс ты создаешь сам себе проблемы:
1. тест так же нестабилен как и код - при изменении кода надо менять тест - упомянутая функция за номером 1 не достигается.

2. Это обычно выглядит не "внесли изменение - тест упал - лечим код", а "внесли изменение - тест упал - лечим тест". Двойная бессмысленная работа, постоянное изменения теста - возможность внесения ошибок - тест - сложный код, вместо выявления ошибок кода, ловятся ошибки тестов, функция за номером 2 тоже не достигается.

Моки имеют смысл когда без них - ну совсем никуда. Например при интеграции с железкой. А если все что надо сделать - это поднять вебсервер или вебсервис - мокать такое - неэффективная трата времени с около-0вой эффективностью.

> Так и не надо писать проверку метода достижения результата.

Проверка последовательности вызовов - это проверка метода достижения результата.

>В одном написаны серия конкретных утверждений A->B

Там где есть мок - это не так.

ответ сразу по многим комментариям:

для меня тест также - это и:
* документация для себя самого (после нескольких лет - я могу посмотреть в него и вспомнить основные модули, где они сидят, что тестировалось больше всего, т.е. где наибольшая сложность
* история разработки. Как я сказал - я пишу функцию, тестирую прямо в унит-тесте, а потом как-есть - переношу тот унит-тест в большой тест. Т.е. в конце проекта набирается громадный набор коротких простеньких тестов
(вместо того чтобы потеряться с дебаггером в глубинах)
* Метод коммуникации с девелоперами. Я могу послать интерфейс в унит тесте и сказать - что вот это - будет работать. Для интеграции - послать унит-тест и сказать - что библиотека работает "вот-так" и например веб-девелопер - интегрирует библиотеку "так как в унит-тесте", с таким же юседжем. Т.е. это- документация кода и для других тоже.
* Метод определить что сломано при переделке. Если тесты покрывают всё (а если изначально они писались - это так и будет) - то при модификациях сложного - сразу видно - где упало и за минуты - исправляем

Насчёт вероятностного подхода.
Дык он везде и во всём. А потом - если вы делаете чексумму - то вероятность её совпадения (или совпадения всех тестов) - близка к нулю.

хочу заметить - что я ниасилил - зачем же нужен этот jester.
Всё сказанное - справедливо для простых юнит-тестов (JUnit)

>хочу заметить - что я ниасилил - зачем же нужен этот jester.

jester ищет непротестированный код. вносит изменение в код и запускает тесты - если не падают - тыкает носом как и что он поменял и говорит бука бука.

олезно только для фанатов test coverage.

>jester ищет непротестированный код. вносит изменение в код и запускает тесты - если не падают - тыкает носом как и что он поменял и говорит бука бука.

всё равно не понял. Как и на что он может менять код?
Это NP-задача. Или проверит все действительные числа перебором? А если такой инпут в функцию и не предполагается никогда?
Ладно, уже по присутствию мавена - в топку, не подходит. Пионерия какая-то. ИБМ любит постить подобное ("Коробочка")

ИМБ как японцы когда-то: скупает всё подряд - надо не надо, все статьи и технологии.
И если в горе мусора найдётся жемчужина - скажет "моё, запатентовано".
Что они только не публиковали...

>всё равно не понял. Как и на что он может менять код?

if (x < 10)

например на

if (x <= 10)
if (x > 10)
if (x == 10)

>Или проверит все действительные числа перебором?

зачем?

>А если такой инпут в функцию и не предполагается никогда?

Значит тесты должны упать.

>Ладно, уже по присутствию мавена - в топку, не подходит.

Мавен это сабжевый grester который есть мавенская обертка над jester.

По твоим вопросам видно ты не понял, что делает жестер. Он не фигачит разный мусор в функции - он делает с точностью до наоборот - он меняет _продакшен код_ и смотрит вызвали ли его изменение падение теста. Если не вызвали - значит то что он изменил - непротестировано. То есть он находит непротестированные инварианты.

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

ну потому я и сказал что тулза для фанатов покрытия тестами.