Тестирование: 3 этапа

3 этаппа:
1. Интерес
2. Пробы и понимание того, зачем это нужно
3. Уверенное владение инструментом

1. Интерес

Прочитать что такое assert() AssertionError и что такое -ea -de (параметры JVM).

2. Пробы и понимание того, зачем это нужно

Почитать книгу о рефакторинге Мартина Фаулера (и обратить внимание на главу 4). Почитать основы Test Driven Development (например вот здесь). И самое главное - побольше практики.
На этом этапе многое не понятно и практически ничего толком не получается. Самое главное 'не забросить это занятие', а продолжать и перейти на следующий этап.
Также на этом этапе придется столкнутся по крайней мере с 2 framework-ам (JUnit и JMock) и очень желательно разобраться что такое модульное/интеграционного/нагрузочное/стресс и другие виды тестирование (что это такое, зачем это нужно и характерные особенности).

3. Уверенное владение инструментом

3. Уверенное владение инструментом
В начале этого этапа приходит некая ясность в вопросах 'зачем нам это нужно', 'чего мы хотим получить' и есть 'некий практический опыт' (как правило он, этот опыт, не очень удачный и довольно карявенький :)). Так вот, на этом этапе главная цель делать все правильно и эффективно (для себя и для проекта).
Тут очень поможет мега книга - Шаблоны тестирования xUnit. Рефакторинг кода тестов. Толстая и вумная книженция, но есть подозрения, что она принесет очень не много пользы, если не пройти первый и второй этапы.

Мысль о Research Reports

Мысль навеяна воспоминаем одного друга о прошлой работе и кое какими событиями на текущей...

Вопрос

Насколько эффективно выполняются research задачи?

Небольшое пояснение

Оставим случаи 'пойди туда, не знаю куда', а рассмотрим какую нибудь простенькую задачку, с внятной целью.
Ну например: 'научится маппить связь один-многие в Hibernate'.
Под эффективностью я имею ввиду не численный показатель, а меня интересует вот что:
Допустим задание было дано человеку, который не знает что такое 'связь один-многие'. Этот самый человек скорее всего сделает следующее:

• сначала почитает что такое one-to-many, заодно и все остальные виды связей;
• потом он найдет документацию, и прочитает какую аннотацию поставить или что прописать в файл маппинга;
• затем (если по хорошему) он попробует сделать небольной примерчик, а может даже найдет какой нить hibernate tutorial.

В итоге мы получаем 3 момента:

• человек потратил примерно день на исследование;
• формально, результатом этого исследования является всего лишь одна строка кода (аннотация)
• все остальные добытые знания, в лучшем случае останутся в голове у исследователя

Есть еще неявный четвертый пункт - если этого человека не будет 'под рукой', а понадобится, ну скажем замаппить many-to-many, в этом случае второй 'исследователь №2' проделает почти такой же путь.

Что не нравится

CXF: Шаг 1 - Описание интерфейса средствами Java

Шаг 1. Описание интерфейса средствами Java.
На мой взгляд, работая с CXF лучше использовать именно 'Java first' схему объявления интерфейса. В основном потому, что манипулируя аннотациями легче получить желаемый WSDL.
Итак, процесс описания интерфейса веб сервиса предельно прост и довольно подробно описан на сайте CXF. Но встречаются мелкие моменты, которые не описаны толком, но при этом не дают спать спокойно.

о том, что 'должен делать разработчик'

Совсем недавно пришлось 'немного' побеседовать с манагерами разных мастей на тему 'что у нас плохо, а что хорошо и что с этим делать'. Я услышал довольно много разных 'разработчик должен делать' и некоторые пункты меня удивили. Вот некоторые из них:

• разработчик должен знать какого уровня железо требуется для проекта (CPU, память и т.д.). Если вдруг, рабочий ПК тормозит, то разработчик должен (ну просто таки обязан) разобраться в чем дело
• разработчик должен принимать самое активное участие в усовершенствовании процессов на уровне проекта и на уровне организации
• разработчик должен заниматься тестированием
• разработчик должен в совершенстве владеть всеми технологиями, применяемыми в проекте, и по другому просто не может быть

Отличия 'get X' от 'find X'

Наблюдение из разряда 'мелочи, которые облегчают жизнь' (и способствуют взаимопониманию).
Есть методы для поиска/получения 'нечто' и есть 2 основных разновидности поведения в случае, если результат не найден (или не может быть получен):

• вернуть null или пустую коллекцию
• толкнуть исключение (например ItemNotFoud)

Впервые на эту разницу обратил внимание в ORM framework-ах. Ка правило, если это метод getXXX, то он либо возвращает результат либо толкает исключение, а если это findXXX, то он возвращает результат либо пустое значение (null или пустую коллекцию).