В смысле?.. Ты не в курсе, что такое юнит-тесты?  

А что это такое?

Это фреймворк для написания тестов к разрабатываемым классам. Очень полезная вещь для разработки проектов в услових меняющихся требований и комадной разработки.
Junit

Добавлено через 3 минуты и 3 секунды
Учимся любить юнит тесты

О, братишка! Мне как раз надо кое-что спрограммисть а времени нет. Возьмёшся?

ЗЫ. Чтобы научиться писать программы надо написать хотябы одну.

Это сообщение отредактировал(а) pompei - 23.10.2007, 11:20

Бумажки(электронные или древесно-волокнистые) используй в любом случае!!!
Даже(тем более) если пишешь один.
Забудешь - не вернёшь. Пиши джавадоку, даже если там тупейший метод(только не пиши "тупейший метод", пиши по сути, как для несведущего соседа).
Ну и всегда пиши хоть маленькую, но бумажку по архитектуре. Себе же полезно будет. Ну а лучше не маленькую бумажку, а хорошую, но небольшую доку.

Это больше чем фреймворк. JUnit - да, фреймворк, а юнит-тесты вообще - это технология. И юнит-тесты не привязаны только к Java, их можно использовать практически везде. Хотя, насчёт LISP я не уверен - не встречался с ним ни разу.
Если кратко, смысл юнит-тестов состоит в том, что сначала ты пишешь код тестирования своего кода (собственно, юнит-тесты), а уже затем пишешь сам рабочий код. Написал один-два юнит-теста - пишешь к ним код. Запускаешь. Добиваешься, чтобы всё отработало правильно (с точки зрения теста). Ничего нового и лишнего при этом в коде быть не должно. Только чтобы тест отработал. Затем придумываешь ещё один-два теста и добиваешься их отработки. Вот так, постепенно, твоя программа сама напишется за счёт "натягивания" её на юнит-тесты.
Честно скажу - впечатление незабываемое. 

Добавлено через 4 минуты и 55 секунд

Согласен с chief39. Если ты не будешь стараться работать по уму, то в будущем не сможешь легко интегрироваться в команду разработчиков. Не думаю, что ты занялся программированием просто чтобы как-то развлечься. А писать до старости водиночку - реально, конечно, но только если денег тебе за это не требуется получать.   

И в результате помимо своей системы получаешь еще тестировочный пакет, который может ее проверить вдоль и поперек.

Юнит-тесты хороши, когда мы тестируем "боевого сферического коня в вакууме", т.е. метод, который складывает 2 и 2 (или обрезает расширение у имени файла) . А вот если метод читает-пишет файлы, работает с БД, с сетью или, не дай бог, с ПО стороннего производителя, вот тогда начинается веселье. :(

Выражение "натягивания" на юнит-тесты" -- это пять! ))

Угу :( Если суть не в простой логике КА, а нужно протестить что-то сложное с "состояниями", причём очень сложными и разнесёнными по разным подсистемам.
"Хороший" юнит тест кэйс может быть размером с целую подсистему     
Кста, для этого ещё полезен dbunit.

Так... а JMock или альтернативными вы как активно пользуетесь? Сегодня только начал читать и тестить, впечатлился возможностями, но в голове каша.

ps в догонку сказанному на первой странице по поводу виртуальной машины. Когда надо было нести прогу в универ, где тоже нет явы.. я просто скопировал на флешку всю ЖРЕ\ директорию : работало на урА  

nornad, я не писал, что не знаю что это такое, я писал, что не понимаю с чем их едят 



Денег, конечно, требуется!!!  Но, есть и другой путь, который, я почти полностью уверен, используется тучей программистов. Когда проект задумывается, простенький и без команды, программист не беспокоится о документации, архитектуре и прочей номенклатуре, он просто пишет код. Когда из зерна начинается проклёвываться росток (т.е. проект пошел в гору), программист начинает задумываться о привлечении команды в проект и только тогда берется за бумажки. Могу привести в пример игру Domestic Cat'а при ее написании он не шипко старался угодить всем стандартам, а просто писал.

ЗЫ: я тут как раз пишу тестовую систему. Т.е. грубо говоря на вход тестируемому модулю поступают данные и возвращается результат, который сравнивается с эталонным. И JUnit натолкнул меня на мысль, что может в качестве тестера мне как раз использовать JUnit? Т.е. есть набор тестов (50 штук к примеру) через них лупится, на первой же осечке выходит из теста. А также существуют ограничения по времени и по выделенной памяти.
ЗЗЫ: простите, что я не так часто появляюсь, просто меня из дома выгнали, щас доступ в инет проблематичен :(

Лично я даже не слышал о таком. Я и юнит-тестами мало пользуюсь. Потому как интерфейс ими вообще не проверишь, а писать мне больше приходится интерфейсного, чем расчётного. В последних моих программах доля расчётов, которые можно обложить тестами составляет процентов десять. Имхо, юнит-тесты в этом случае уже не так полезны. Хотя в критических местах (где есть сложности с расчётами) применить всё же можно и зачастую нужно.


Ну, на такую JRE другие программы (чужие) завязать сложнее. Хотя при желании тоже можно. В принципе, Java не требует непосредственной инсталляции в винде.

Добавлено через 7 минут и 2 секунды

Это пример проекта, который был создан ради развлечения и не предполагал ни передачи кода другим разработчикам, ни развития проекта в будущем.
Достаточно яркий пример написания "фор фан". Если так писать за деньги, то будешь не очень хорош в команде. На маленьких проектах - вполне нормально может получаться долгое время. Но в итоге всё равно на одном из проектов придёшь к стадии, когда надо передать кому-то код. С документацией. И вот тут-то о тебе и сложится антересное мнение окружающих коллег.   


Ну да. Зачем писать своё такое же? 
Только тесты в JUnit, кажется, все прогоняются, а не "по первой осечке". Хотя, я с JUnit не работал. Тесты писал больше на сях. На Java пока не требовалось. 

Вот, я как раз и описывал. Еще 1 аргумент. 2-3 энтузиаста собрались. А как мы знаем на голом энтузиазме далеко не уедешь, его хватает на 3-4 недели, а если ядреные энтузиасты то месяца на 3-4, не более. Так вот представьте, что это ценное время они стали тратить на написание документации и тестов. Пока они писали энтузиазм испарился в 2 раза быстрее + написанного целевого кода в 2 раза меньше. Итого в 4 раза меньше результата. !!! Я не говорю о том случае, когда ты работаешь в организации, и тебе не важно как долго, главное платят деньги. !!!

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

Спасибо alex_nevolin за статью, описанное принято к сведению.

Не согласен. Писать проектную документацию не должны все скопом - это не только у голых энтузиастов потерпит поражение, но и у "одетых". Документирование же кода отнимает времени совсем немного, если производить его в процессе, а не после.


Покажи мне ту организацию, где платят хорошие деньги за "неважно как долго", я туда уже хочу. 


Хорошо, если альфа. Но скорее это будет вообще макет, код которого в будущем использовать не стоит. Голый энтузиазм и отсутствие нормального проектирования с закреплением решений на "бумаге" приведёт к тому, что код будет не прямо-таки смердить. Да и документирование у тебя будет в стиле "эте не баг, это фича".

А вообще это обсуждение корректнее уже вести в разделе "Управление проектами". Непосредственно к одной лишь Java отношения оно уже не имеет.