Здравствуйте.
Недавно написал небольшую программу. 
Там всегото происходит html  разметка С#  кода и потом его расскраска.

Но  в целях обучения мне сказали что, нужно создать для неё с-му автоматического тестирования.
И сделать поскорее.

Как это сделать с чего начать?
Я почитал в нете но всё равно я несовсем предстовляю как это должно выглядеть.

Читайте про Unit Test'ы, для начала тут и тут.
Инструментарий, например, NUnit (офф. сайт) или встроенные тесты студии.

Пример с NUnit.org:
Класс:


Тест к нему:



Это сообщение отредактировал(а) Ram1reS - 11.12.2009, 10:24

в профессиональной студии есть вазможность создания тестов

Я тут так подумал. Конечно, юнит-тесты нужная вещь, но если пишешь что-то относительно больше в одно лицо и нужно быстрее разработать, то если ещё и юнит-тесты ко всем функциям писать, то кодить сутками придётся)))))

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

Думается, в критических местах использование тестов уместно.

спасибо всем.
Почитал про  NUnit, вроде понял.
Буду пробовать.

Ram1reS отдельное спасибо++

Всем привет!

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

Вроде нормально, только один вопрос. Вы этот код специально нечитабельным сделали? Такое ощущение что кодили в старом добром блокноте)))

Сорри.
Это с непривычки.
На самом деле очень удобно и читабельно.

P.S. Добренькому папаше.

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

да ладно вам. есть программы в которых уже нету ошибок...

сомневаюсь, не видел таких программ...

gwi52, имхо: ну мб и дело привычки, но такой код сложно читаем) и не подходит не под какие стандарты)

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

парень не смей такое делать...
ну по крайне мере в команде такое делать нельзя.
лучше учись воспринимать любой вид.

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

Так что, безусловно, правила нужны, но не догмы.

У меня в практике бывали случаи, когда только форматированием я добивался понимания, а затем и оптимизации, в результате которой программа начинала работать в 100 (сто) раз быстрее.

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

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

Это нервы...
"... учись воспринимать любой вид ..." 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.

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

-