Хорош бредить, тот код, который вы привели полное ###. Вам на это указали. Форматирование и именование производиться в соответствии со спецификацией, а не как моей задней левой вздумается.

Серьёзные люди такого не пишут. 

Это нервы...
"... учись воспринимать любой вид ..." DenWPF
Уже не интересно...
Гуд бай !

Хм...
Да интерестный вышел спор.

Но мне интересно, как вы считаете 
когда нужно применять тестирование, а когда можно обойтись без него?

На ваш взгляд, есть ли некое универсальное правило?
Применяем в этих случаях и не требуется в этих.




Это сообщение отредактировал(а) KuMa1104 - 12.12.2009, 00:39

будет ли желание приводить к примеру такой код к "нужному виду" (тут изменено только форматирование, без использования ужасных имен переменных)


или хотелось бы видеть сразу более читаемый код ?


Добавлено @ 18:04
лично мне, было бы приятнее сразу видеть второй вариант из этих двух

Добавлено @ 18:08


Это сообщение отредактировал(а) Exai1e - 12.12.2009, 18:26

Он считает, что надо писать говёно, чтобы говорить: "Зри в корень!, а не на форму. Учись читать любой код!".
Чтению кода посвещены книги, которые предлагают кое-какие советы для разбора чужого кода. Учится тут ничему не надо (сугубо практика).
Это не значит что ты должен писать говёный код, чтобы говорить "Практикуйтесь!".
Учится надо писать нормальный код.

Это сообщение отредактировал(а) ДобренькийПапаша - 12.12.2009, 20:00

К вопросу о том, как форматировать код... Используйте в студии ReSharper и будьте счастливы, авто-реформат во время написания и нажатием пары кнопок для всего кода. И никаких проблем со стандартизацией и фразами "а мне удобно". Не мне удобно, а как надо! Кстати, дело привычки, поэтому к "как надо" тоже привыкнуть легко. Было бы желание.

вроде тема о юнит тестах 

объясните , почему мы обсуждаем редкостный г@код?
а вообще да, Resharper очень сильно помогает с рутинными действиями

Мужики! Вы зачем здесь собрались?

Откройте отдельную тему по форматированию текста и кувыркайтесь там до посинения.
Здесь же автор темы задал простой и конкретный вопрос по тестингу.
Я привел 20 строк текста программы, в которой была изложена концепция тестирования. 
Ровно через 5 минут от Папаши появился отклик, из которого следует, что Папаше моя программа понятна, но как-то не совсем нравится.
Последние два поста содержат видимо различные варианты чего-то одного. Но каждый вариант - это 200 строк не очень простого кода.
Сравните мои 20 строк, которые через пару минут понятны любому, и 2x200, анализировать которые нет никакого желания.
Не забывайте, читабельность - это, прежде всего, компактность и обозримость.
Все, эта тема закрыта.

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

На последний вопрос автора темы отвечу так. Если для Вас программирование - это приятная прогулка, то тестировать не надо, не забивайте себе голову всякой ерундой. Но если это Ваш хлеб, если Вы цените свою клиентуру и, главное, свое реномe, если Вы разумно ленивы, т.е. не хотите через месяцы и годы возвращаться к своим давно забытым программам для устранения дефектов, то отнеситесь к тестированию со всей серьезностью.
Моя дочь, программер, трудится в Америке в одной не очень крутой, но очень ответственной дивелоперской фирме, которая жесточайшим образом регламентирует не только форматирование текста программ, но и тестирование каждого произведенного модуля, т.е. они параллельно создают библиотеку тестов, доступную по любому поводу и для любого модуля. И это очень и очень правильно. Не получается быстренько что-нибудь попрограммировать.

Останусь при своём мнении. В вырожденных случаях этого делать не стоит. Например в вашем коде вначале, тест не нужен. 

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

Sorry! Пресловутое форматирование.

Всем привет!

И все таки не дает мне покоя программа в этой теме от автора Exai1e, 12.12.2009, 18:02.
Отсутствие критики этой программы и популярность темы, >250 просмотров, видимо,
требует от меня пояснений. 

При всем уважении к Exai1e, человек за деревьями не увидел леса. 
Он представил нам образец форматирования текста программы,
в которой собран весь возможный утилитарный сервис по вводу тестовых примеров, 
редактированию, копированию, сохранению и пр. Но идея оперативного тестирования 
в этой программе отсутствует. А вся соль-то именно в оперативности.

Попытаюсь на примере программы (см.дальше) объяснить более подробно.

Исходный класс, myClass, содержит 4 метода, Summary,Sum,Mul,Div, 
для вычисления несложной арифметики с такой же несложной ограничительной логикой.
Тестирующий класс, tester, содержит аналогично названные методы,
в каждом из которых формируется список тестовых образцов типа List<string>, 
в которых наряду с исходными параметрами записывается ожидаемый результат вычисления.
Затем эти образцы поочередно подсовываются в тестируемый метод исходного класса и 
сравниваются с ожидаемым результатом, несовпадение сопровождается соответствующим 

сообщением.
Тестирование инициируется кнопкой buttonTest после отметки соответствующей радио-кнопки,
вычисление инициируется кнопкой buttonStart после заполнения соответствующих текст-боксов.
Все контролы расположены рядом.

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

Подчеркну, в проект одновременно включаются как исходные классы, так и тестирующие,
т.е. параллельно создаются две библиотеки - библиотека исходных классов и библиотека 

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

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

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

gwi52, не изобретайте велосипед, используйте встроенные тесты студии. Или nUnit.

По поводу форматирования - проявите уважение к остальным участникам. Человек может съесть любое д прочитать любое спагетти, но не стоит после спрашивать его о вкусе и послевкусии.

-