Практически ни для кого не секрет, что при тестировании кода, использующего какие-то внешние компоненты, часто применяют подход mock-объектов. Для тех, кто всё же о нём не знает, кратко поясню: это такие объекты, которые имеют тот же интерфейс, что и используемые компоненты, но их поведение полностью задаётся в тесте, и их использование позволяет избежать поднятия полной инфраструктуры, необходимой приложению для запуска. Что ещё более важно, можно легко и непринуждённо проконтролировать, что код вызывал те или иные методы у mock-объекта с теми или иными аргументами.

В этой статье я проведу сравнительный анализ двух распространённых в Java библиотек для работы с mock'ами: EasyMock и JMock. Для осознания достаточно базового знания JUnit, а после прочтения этой статьи у вас будет весьма хорошее представление о том, как пользоваться обеими этими библиотеками.

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

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

После года разработки и трех релиз-кандидатов команда SpringSource презентовала новую версию веб фреймворка — Grails 2.0. Я часто использую Grails в своих проектах и внимательно слежу за процессом разработки и выпуска новых релизов.

Интересно заметить, что изначально релиз планировался под версией Grails 1.4, но фундаментальных изменений оказалось слишком много, и Grails присвоили версию 2.0.
Итак перечислю, что нового появилось в новой реинкарнации Grails:

Несколько часов назад на github-е популярного TDD-фреймворка JUnit появилась финальная версия JUnit 4.9. Что же вошло в долгожданный релиз?

Думаю, почти каждый сталкивался с таким мнением: писать тесты сложно, все примеры написания тестов даны для простейших случаев, а в реальной жизни они не работают. У меня же за последние годы сложилось впечатление, что писать тесты — это очень просто, даже тривиально^*. Автор упомянутого выше комментария далее говорит, что неплохо было бы сделать пример сложного приложения и показать, как его тестировать. Попробую именно этим и заняться.

^*)Писать сами тесты — действительно элементарно. Создать инфраструктуру, позволяющую легко писать тесты — чуть сложнее.

Наверняка все знакомы с таким понятием как test-driven development(TDD). Наряду с ним также существует такое понятие, как data-driven testing(DDT, не в обиду Шевчуку) — техника написания тестов, при которой данные для тестов хранятся отдельно от самих тестов. Они могут храниться в базе данных, файле, генерироваться во время исполнения теста. Это очень удобно, так как один и тот же функционал тестируется на различных наборах данных, при этом добавление, удаление или изменение этих данных максимально упрощено.

В предыдущей статье я рассмотрел возможности JUnit-а. Там примерами такого рода подхода могут служить запускалки Parameterized и Theories, в обоих случаях один тест-класс может содержать только один такой параметризированный тест(в случае Parameterized несколько, но все они будут использовать одни и те же данные).

В этой статье я заострю внимание на тестовом фреймворке TestNG. Многие уже слышали это название, и перейдя на него, вряд ли желают вернуться к JUnit-у(хотя это только предположение).

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

Итак, техника довольно понятна, но встает вопрос, что использовать для написания этих самых тестов? В этой и других статьях я хотел бы поделиться своим опытом в использовании различных инструментов и техник для тестирования кода в Java.

Ну и начну с, пожалуй, самого известного, а потому и самого используемого фреймворка для тестирования — JUnit. Используется он в двух вариантах JUnit 3 и JUnit 4. Рассмотрю обе версии, так как в старых проектах до сих пор используется 3-я, которая поддерживает Java 1.4.

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

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

Компания SUN даже придумала специальный формат javadoc — «стандарт для документирования классов Java». В моей практике было совершенно обычным явлением, когда какой-то код не проходил Code Review, потому что в нём у некоторых методов отсутствовали комментарии.

Я утверждаю, что этот подход устарел, и сегодня я расскажу, почему комментарии — это зло.

В данной статье я хочу рассказать начинающим Java разработчикам, как написать простое веб приложение, используя популярный фреймворк Spring Framework.

При разрабокте приложения мы будем использовать утилиту Ant для автоматизации действий и изучим, как писать простой тест с помощью библиотеки JUnit. Весь код будем писать в Eclipse IDE.

Статья написана на основе первой части руководства «Introduction to Spring MVC». Вам достаточно иметь лишь общее представление о Spring, чтобы прочитать статью с пользой.

Так что милости просим :)