Лично я обнаружил, что чтения эссе или двух JUnit, подчеркивающих, что «ты пишешь тест перед кодом» было достаточно, чтобы начать меня.
Наиболее важной частью в изучении этой технологии является написание МНОГО кода , основанного на тестах , потому что вам нужно изменить некоторые из самых основных способов написания кода. Вещи как:
- Написание теста перед кодом заставляет вас задуматься о том, как вы будете вызывать свой код и получать результат обратно. Это означает, что вы сначала разрабатываете API, основываясь на том, как вы будете его использовать. Это часто приводит к лучшему API.
- Ваш стиль кодирования изменится, потому что вам НУЖНО думать более модульно, чтобы иметь возможность тестировать части кода вместо всего этого.
- Вы также достигнете точки, в которой вы сможете с уверенностью вытащить основной блок и вставить новый блок вместо того, чтобы вести себя так же, потому что ваш тест пройден. Я сделал это недавно с библиотекой разбора даты, поскольку оригинал был слишком снисходительным.
Лучшее место, чтобы начать с малого, это с вашей утилитой. В следующий раз, когда вам понадобится один, просто спроектируйте его сначала с помощью тестов, напишите множество тестов, охватывающих все ваши официальные сценарии использования (включая то, что должно происходить с переданными нулевыми значениями и т. Д.), И когда все варианты использования будут реализованы, вы сможете использовать это прямо в вашем коде, и будьте уверены, что он работает как положено.
По моему опыту, хорошие тесты могут выполнять дополнительную работу в качестве документации, потому что у вас есть много очень лаконичного кода, точно говорящего о том, как код ведет себя в различных ситуациях, что может быть легко доказано как корректное (зеленая полоса). С осторожными комментариями вы не получите это намного лучше чем это.
Для Java версия jUnit 4 действительно хороша.