Как заставить себя писать юнит-тесты?

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

TDD не предлагать. Я никогда не объясню это заказчику.

А что, заказчик следит за тем, как ты пишешь каждую строчку?

главное - начать, а дальше не захочется бросать дело, на которое потрачень n сил

для начала отказаться от отдела тестеров и начать ценить своё время)

TDD не предлагать. Я никогда не объясню это заказчику

А зачем это объяснять заказчику?

Сделать средней сложности проект в один смычек без ТЗ. Как правило, после того как несколько раз невзначай поломаешь то, что «гадом-буду-вчера-работало», желание писать тесты появится само собой, как бриться, чистить зубы, мыть руки с мылом.

Кстати TDD и юнит-тесты, абсолютно параллельные понятия.

Зачем себя приучать делать ненужное? Видишь опасное место - написал тест-проверку, если и так уверен в коде - нафига время тратить?

как приучить себя писать тесты на каждый чих

Не нужно их писать на каждый чих. Тесты нужны тогда, когда тебе необходимо изменять код. Чувствуешь, потянулись загребущие ручонки к клавиатуре — будь добр, проверь наличие тестов для всего, что потенциально могут затронуть твои изменения. И делать push origin можно лишь тогда, когда тесты проходят и до, и после.

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

Говоришь себе: «Ломай меня полностью». Как в этом видео: http://www.youtube.com/watch?v=Xk0y7AToCe8

Сломайте дебагер. Потребность в юнит тестах сразу станет очевидной. Через некоторое время про дебагер просто забудете. Тренироваться можно на серверном приложении. Его, как правило, дебагером хлопотно.

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

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

Никак, ты должен захотеть писать тесты.

Собирай покрытие юнитестами и смотри ка кна графике оно растет. Также можно выдвать степень покрытия как метрику заказчику. Типа «в этом квартале, я планирую достичь покрытия 10%»

Извините, мой психиатр не разрешает

Пусть с ним поговорит мой личный алюминиевый пудель!

Не надо себя заставлять. Жизнь заставит.

у него врожденная боязнь алюминия и пуделей

У меня возник вопрос. Как писать тесты для более-менее абстрактных вещей, я могу понять. А как быть, например, с классом, хитро опрашивающим определенные события в конкретной операционной системе? Создавать отдельную виртуальную среду с этой операционкой, грузить туда и выполнять?

Ох уж эти пирожки.

Мокинг.

EasyMock: http://www.youtube.com/watch?v=MMGSwEcjzV4