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

Ссылки:
  » Туториал на хабре
  » JUnit в NetBeans
  » Rutracker на эту тему
  » Официальный сайт

  » Вдохновение для юнит-тестов
  » «Я не пишу юнит-тесты, потому что ...» — отговорки

  » Поучительная презентация почему нужен TDD
  » Бек К. "Разработка через тестирование"

На самом деле интересует больше сама техника разработки, хотелось бы обсудить её аспекты. Возможно, убедить некоторых пользователей в её нужности/ненужности, а потом закрепить это в выводе, сделав презентацию/отчет.

Знаю, что Oak её ненавидит, а aNNiMON не понимает, зачем она нужна.

Ксакеп, я пока что не сталкивался с потребностью в тестах вообще

Ксакеп, я не понял суть предварительных тестов?

Ксакеп (16.03.2014/20:58)
На самом деле интересует больше сама техника разработки, хотелось бы обсудить её аспекты. Возможно, убедить некоторых пользователей в её нужности/ненужности, а потом закрепить это в выводе, сделав преПрисоединюсь к Дубу и Аннимону, и лично и на работе не применяется. Юнит-тесты для готового кода - да, но не ТДД.
Кстати написать толково Юнит-тест тоже уметь надо. Был недавно казус когда баг пришел от пользователя, хотя легко воспроихводился юнит-тестом. Вывод: не давайте писать тесты студентам

JUnit насколько помню автоматом генериться для готового кода, точнее шаблоны тестов

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

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

да и кого знаю из ребят работающих в кампаниях программистами - про тесты не слышали/не знают/забыли
юзера ничто не заменит, и компилятор убережет такой вот девиз

Ксакеп (16.03.2014/20:58)Знаю, что Oak её ненавидитНу, не то, чтобы ненавижу, но.... Станислав 16.02.14
знаешь чо такое ТДД
это *уйня

Тут пообщался с одним человеком, работавшим в Google:Если вы имеете в виду test-driven development, то я ее не использую ни на работе ни в личных проектах. TDD предполагает, что с самого начала абсолютно понятно, как должна вести себя программа. В реальной жизни такого не бывает. В результате получается, что все равно тесты потом подгоняются под программу. Вообще с тестированием у меня сложные отношения. Я понимаю, что тесты важны и нужны, но всегда жалко тратить время на тщательную разработку тестов. Обычно я полагаюсь на работу команды тестировщиков, а личных больших проектов, которые требовали бы тщательного тестирования, у меня нет.

Это не означает, что я вообще не пишу тестов. Пишу, и частенько это помогает мне находить ошибки. Только я пишу их всегда уже после того, как программа в целом закончена, и мне становится ясно, где у программы могут быть слабые места, а за какие части я совершенно спокоен.

Вообще я пережил много разных "технологий программирования" - от "структурного программирования" до всевозможных видов agile'а, в любой технологии есть свое рациональное начало, только не надо относиться к ним как к средству, которое спасет любой проект от краха. Мне близок подход Гугла к проектированию - если команда состоит из инженеров высокого класса, то это является гарантией успеха, независимо от того, как команда работает. Хотя, конечно, определенные общие корпоративные правила есть и в Гугле, например, что каждый фрагмент кода перед коммитом в общий репозиторий должен быть просмотрен другим человеком (обычно из той же команды). И это разумное правило.Так что как-то так.

+1 гугловцу