Unit тестирование и Jackrabbit (JCR)

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

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

Тестирование: начало (ч.2)

Размышления на тему: "что надо сделать, чтобы превратить загадочное слово 'тестирование' в нечто реально полезное для разработчиков?"
Ответить на ряд вопросов:
1. Чего мы хотим добиться?
2. Нужно ли нам это?
3. Можем ли мы это себе позволить?
4. Заниматься этим систематически, т.е. постоянно (это не вопрос, а утверждение).

Мысля о качестве ... и не только

По долгу службы сейчас "изучаю" CMMI. А еще часто на проектах пытаются измерить качество. А еще качество, ну это "такое замечательное" свойство...
Вообщем, родилась некоторая аналогия между этими явлениями. Начнем с конца.

CXF: Шаг 0 - XSD to Java

Почему шаг 0?

Почему шаг нулевой: на мой взгляд этот шаг имеет нулевую пользу и если это возможно, нужно его пропустить. Почему?

• Мы в этот файл вкладываем информацию о типах данных, которыми будем оперировать в интерфейсах. При преобразовании XSD to Java эта информация изменится (возможно довольно сильно), при преобразовании Java to WSDL получившаяся измененная информация еще больше исказится.
• Все комментарии, разметка и прочая вспомогательная информация, заложенная в XSD, уйдет "в никуда".
• Ну и куча "мелочей", от лишних 10 сек при компиляции до необходимости хранить знания об интерфейсе в двух раздельным местах на двух разных языках.

Если вышенаписанное не убедило отказаться от написания XSD или по другому не получается, то вот несколько рецептов "от головной боли":

Экономия или скупость?

Лирическое вступление

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

Вот работал я в организациях где к вопросу железа подходили ну довольно просто, в 3 этапа:
1.Со старта дают нормальный (достаточно мощный ПК)
2.В случае надобности, делают апгрейд в довольно короткие сроки (1-10 дней).
3.И сервера, как правило, работают на действительно серверных железках (а не хламе, который остался от прошлого апгрейда).

А вот бывают случаи противоположные. На проекте хронических дефицит ресурсов(железных) - ПК программистов слабенькие, билд серверу не хватает памяти для своего нормального функционирования и т.д. Запросы на добавление памяти(ну супер дорогой ресурс!) либо обрабатываются месяцами, либо на них забивают. И аргументы как всегда железные: «это дорого» и «сейчас нету средств».

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

Появилась мысль, что нехватка оперативки и "черепаший" винчестер должны воровать не только нервы у разработчиков, но и деньги у организации. И появилась идея, прикинуть сколько это стоит? И стоит ли...? :)

Задача

Итак, условие задачи:

Тестирование: начало

Итак, тестирование в жизни программиста.

Все знают что такое тестирование... или, по крайней мере, так думают :) Написано довольно много книг и статей об этом, выдуманы методологии и практики (ну например TDD) и даже заложены базовые механизмы в "недра Java". И во всех книгах\статьях\презентациях наперебой утверждают что это круто (в смысле unit тестирование), что это жизненно необходимо, и вооще - JUnit спасет мир.

Во как!
И что?!

Подсветка синтаксиса

Вот захотелось получить 2 вещи:
1. Автоматическое экранирование угловых скобок
2. Красивое отображение кода

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

Итак, есть вот такая библиотека.
В двух словах о том, как это работает: с помощью JavaScript в коде страницы ищутся теги с определенными признаками (например <pre> с определенным классом), текст в этих тегах рассматривается как фрагмент исходника, со всеми вытекающими. Т.е. этот текст можно раскрасить и добавить всяких рюшичек (номера строк, выделенные нечетные строки и т.д.). Получается довольно симпатишно:)

Почитать как "это" подключить можно здесь, почитать про дополнительные настройки и стили здесь и здесь. Тем, кому не нравится тег <pre> будет интересно прочитать вот это.

Ну и если очень хочется, можно почитать про подобные "плагины" ( например здесь).