Экстремальное программирование

[Igel]

Начало см. тему "Паттерны проектирования".

Значит вопросы касаются пока написания тестов.
Просто не представляю как писать, хотя особенно и не думал.
Тут возникают вопросы :
  Писать-ли для каждой процедуры или для задачи? Или разбивать на некие куски и создавать тесты для них?
  Тем более если нет четкого представления о решаемой задаче, как можно создать тест? Тут я в тупике, сказывается отсутствие опыта.

[Alf]

Тем более если нет четкого представления о решаемой задаче, как можно создать тест?

А что тестировать, если нет четкого представления о задаче? Как можно разработать программу, считающую неизвестно что?

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

Если ты не представляешь, каким образом можно оценить решение задачи, значит, бесполезно браться за программирование, нужно продолжать (начинать?) анализ. Так же бесполезно что-то тестировать в этои случае. Программа выдает какие-то цифры, а ты не знаешь, правильны они или нет. Разве что проверить, что не вылетает по ошибке, но этого маловато, чтобы судить о качестве.

Тут на самом деле два больших вопроса:

1. Что и как тестировать?
2. Чем тестировать?

[Igel]

Alf, ты прав. Это я с текущего положения так неудачно выскзался.
По поводу оценки решения задачи. Реализаций этой задачи может быть несколько. Оценить можно пока только со своего опыта.
Одна из идей, вычитанная - это возможность на этапе составления тестов уточнить спецификацию задачи или элемента.
Ясно понятно, что без анализа никуда.
По поводу вопросов присоединяюсь с уточнениями.
1. Как определить, что тестировать? Какие рекоммендации для начального уровня?
2. Есть-ли инструменты по созданию тестов ? (В книжке упоминалось, но не конкретно)

[Антон (LogRus)]

Igel, относись к тестам, как к проектированию на этапе написания теста ты решаешь каким будет поведение системы, т.е. фактически дополнительно документируешь
такая у нас политика партии на предприятии

пишешь тест проектируешь
пишешь код проектируешь
дорабатываешь тест снова проектируешь
код постоянно перерабатывается и это хорошо сплошной не прекразающийся цикл разработки: рефакторинга и тестов

тесты нужно писать и на каждую функции(unit-test) и на функционал отдельно в идеале функциональный тест должен уметь получать тестовые данные из вне, такми образом ты разгружаешь службу тестирования котороя может загнать в автотест свои тестовые данные и вместо много часового тестирования у тебя будет 3 минутный тест который можно запускать чуть ли не каждый час после нахождения ошибки которую не покрыл тест имеет смысл его дополнить.
при написание тестов я использую заглушки вместо внешних классов по отношению к тестируемому функционалу
в качестве заглушек в зависимоти от особенностей реализации используются или наследники интерфесов или стратегии шаблонов
библотеку boost::test
XML сериализацию boost::serialize для загрузки тестовых данных в функциональных тестах

[ysv_]

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

[Alf]

По поводу вопросов присоединяюсь с уточнениями.
1. Как определить, что тестировать? Какие рекоммендации для начального уровня?
2. Есть-ли инструменты по созданию тестов ? (В книжке упоминалось, но не конкретно)

Сразу на оба не отвечу, слишком объемно. Давай начнем с первого - что тестируем?

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

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

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

1. X = -1, Y = -1 - ошибка.
2. X = 0, Y = -1 - ошибка.
3. X = -1, Y = 0 - ошибка.
4. X = 1, Y = -1 - ошибка.
5. X = -1, Y = 1 - ошибка.
6. X = 0, Y = 1 - 0.
7. X = 1, Y = 0 - 0.
8. X = 1, Y = 1 - 1.
9. X = 2, Y = 1 - 2.
10. X = 1, Y = 2 - 2.

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

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

Код:

if ((X = 7.25) AND (Y = 3.14)) then Area = 10000.0;

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

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

А вот если ты решил исповедовать XP, то можно сразу написать тесты (пока опускаем вопрос - как имменно), а потом писать код, который позволит им выполниться без ошибок. Например:

Код:

if ((X < 0) OR (Y < 0))
  сгенерировать ошибку "недопустимый аргумент";
if ((X = 0) OR (Y = 0))
  return 0;
return X * Y;

Можно писать такой сложный код не сразу целиком, а частями, и тут же прогонять тесты. Например, после того, как введены первые две строчки, должны успешно завершиться тесты с 1-го по 5-й. Разумеется, второе сравнение с нулем в данном случае излишне, но в общем желательно проверять подобные особые случаи.

Если с первым вопросом - что тестировать - появилась ясность, переходим дальше - чем тестировать, и как написать эти самые тесты.

[Igel]

Alf, сразу вопросы,по организации.
1. Т.е. на одну задачу набор тестов? А не может один тест - контролировать набор параметров?
2. А вот как сделать проверку автоматизированной? Есть решения готовые?
  Т.е. написание теста можно разделить на этапы:
- анализ задачи - изучение предметной области
- определение критериев теста
- Написание теста
- Включения теста в систему проверки.

Но получается нужно тест делать связанным с программным кодом? А потом для интеграции нужно код отрывать от теста?

[Igel]

А про Unit-тесты где можно глянуть?

[Антон (LogRus)]

ysv_, смысл есть. правльно написанный функциональный тест, снимит нагрузку с тестеров и даст им возможность дополнять тесты, если будут найдены ошибки в будующем, пропущенные автотестом.
Я считаю, что все тесты лучше прикрутить к автосборке(на www.gnu.org есть готовый проект), которая ночью собирёт проекты и запустит тесты, результаты посмотрите утром, вдруг чей-то код сломал связанный объект.

как уже говорил, в тех функциональных тестах, что мне приходилось видеть(делать) тестовый случай представлен ввиде структуры со всеми входными и выходными данными, далее берём входные данные(из упомянутой структуры) отдаём в тестируемый функционал, результат сравниваем с эталоном. Один раз требовалось вводить дополнительные флаги, на вроде зачистки данных перед тестом, если тестируется интелектуальный контейнер и тестовые случае связанны в цепочки. все тестовые случаи это вектор, тестовые случаи загружаются из файла через XML сериализацию boost.

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

[Alf]

Alf, сразу вопросы,по организации.
1. Т.е. на одну задачу набор тестов?

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

Вообще будь морально готов к тому, что объем тестового кода в 2-3 раза превысит объем самой программы.

А не может один тест - контролировать набор параметров?

Не понял вопрос. Проясни, пожалуйста, как ты это видишь.

2. А вот как сделать проверку автоматизированной? Есть решения готовые?

К счастью - есть. Если по составу тестов вопросов больше нет, переходим к этому.

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

Связанным физически (в смысле должен находиться в том же файле) или логически (содержимое теста зависит от конкретного кода)?

А потом для интеграции нужно код отрывать от теста?

Что есть интеграция? Непонятно.

А про Unit-тесты где можно глянуть?

Если читаешь по-английски, могу прислать хорошую книгу "Pragmatic Unit Testing". Она посвящена тестированию в среде NUnit для C#. Хороша она тем, что не сводится к банальному "в меню X выберите опцию Y, появится окно...", а описывает методологию unit-тестирования как такового. Есть ее вариант для Java, если тебе он подойдет больше, поищи в сети.

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

[Igel]

А не может один тест - контролировать набор параметров?

Не понял вопрос. Проясни, пожалуйста, как ты это видишь.

Сам плохо понимаю. Это вопрос скорее определения - что есть тест!

2. А вот как сделать проверку автоматизированной? Есть решения готовые?

К счастью - есть. Если по составу тестов вопросов больше нет, переходим к этому.

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

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

Связанным физически (в смысле должен находиться в том же файле) или логически (содержимое теста зависит от конкретного кода)?

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

А потом для интеграции нужно код отрывать от теста?

Что есть интеграция? Непонятно.

Т.е. несколько разработчиков решают разные задачи проекта, создают тесты, пишут код. Но наверняка нужно потом необходимо собрать, например в некий модуль. Т.е. я неверное слово вставил не интеграция, а КОМПОНОВКА.

А про Unit-тесты где можно глянуть?

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

Согласен!  Обоими руками за. А вот за книжку спасибо, но с англицким у меня туго..

[Alf]

Это вопрос скорее определения - что есть тест!

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

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

А мы говорили о составах?

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

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

Эту фразу я не понял. Как выглядят изменения в смежных программах? Ведь не изменения же их кода имеется в виду.

Имелась ввиду именно физическая связь.

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

[Igel]

Всем привет! Вырубили инет, только починили.

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

ДОговорились. Думаю вопросы будем решать по мере их возникновения.

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

Эту фразу я не понял. Как выглядят изменения в смежных программах? Ведь не изменения же их кода имеется в виду.

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

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

На вскидку что-то не идет в голову... Подумаю, сформулирую, завтра постараюсь ответить...

[Hooter]

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

Имхо, нужно ввести не только определение теста модуля, но и определение вход-выходных параметров. Например, это - набор условий, при выполнении которых можно сказать, что тест выполнен успешно (я тут своими словами, так что звиняйте, если что... ).

В приведенном примере:

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

и т.д.

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

[Sel]

Igel, на какой стадии проект?

[Igel]

Igel, на какой стадии проект?

На стадии УЖАС.
На самом деле меня не устраивает существующая методика разработки. Поэтому изучал различные и остановился на ХР.
На текущей стадии внедрять ХР в проект не вижу смысла.
Но есть уже задумки на модернизацию и изменения. Осложнено все тем, что заниматься этим буду пока один. Поэтому хочу понять и начать с тестов. Прикину структуру, спроектирую костяк и хочу попробовать сделать для первой задачи тесты, пока только в свободное время. Которого пока мало.

[Sel]

Хм. Думаю, тебе стОит попробовать выложить свои задумки и разработки сюда. Найдется кто-то, кто поможет. А?

По поводу времени... Его у всех мало, не так ли. Так что давай начинай действовать, пока идея совсем не забылась.

[Igel]

Sel, Тут проблема с косноязыкостью. Думаю трудно мне будет изложить задумки, но я попробую.
Но это пока оффтоп.  Или я не прав?
А если ложить, то в отдельную тему - аля дневничок идей и задумок?

[Sel]

Sel, Тут проблема с косноязыкостью. Думаю трудно мне будет изложить задумки, но я попробую.
Но это пока оффтоп.  Или я не прав?

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

А если ложить, то в отдельную тему - аля дневничок идей и задумок?

Дневник - это хорошо, конечно... но... В названии ветки заявлено нечто иное... Или я не права?

Время идет, дело стоИт. Или -таки что-то делается?

[Артем]

Igel, на какой стадии проект?

На стадии УЖАС.
На самом деле меня не устраивает существующая методика разработки. Поэтому изучал различные и остановился на ХР.

 "...та же фигня, Ромео" (с)


Существующая (у нас на предприятии)  методика разработки меня тоже совсем не устраивает.
Вот только XP как-то не приглянулось, я больше рыл в сторону более глубокого проектирования, до начало кодирования, т.е. чтоб к моменту, когда я запускаю Студию вся программа уже была "написана" (ну, хотя бы очень глубоко продумана и как-то отображена на "бумаге").

Это я все к тому, что тоже готов обсуждать/критиковать/предоставлять различные "задумки", насчет методики разработки ПО. Впрочем, это действительно далековато от заявленной темы

а насчет XP, первое (и, пожалуй, основное) что мне не очень понравилось -- это, то что заказчик не будет знать, что получит, пока это не получит

[Igel]

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

В принципе не против.

Время идет, дело стоИт. Или -таки что-то делается?

В основном идеи роятся... а работается пока только на работе.

[Igel]

я больше рыл в сторону более глубокого проектирования, до начало кодирования, т.е. чтоб к моменту, когда я запускаю Студию вся программа уже была "написана" (ну, хотя бы очень глубоко продумана и как-то отображена на "бумаге").

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

Мне приглянулся один существенный аспект - система предварительных тестов (заколебался совмещать несовместимое и выдумывать черт знает что).

что мне не очень понравилось -- это, то что заказчик не будет знать, что получит, пока это не получит

По идее он с самого начала будет знать что ему нужно. А то, что ты говоришь - это и есть классическа разработка. Как бы детально не было проработано ТЗ - получится то, что смог сделать разработчик.
В ХР подразумевается, что заказчик участвует в проекте - по этому знает о проекте все с точностью, которая и не снилась.

[Dimka]

а насчет XP, первое (и, пожалуй, основное) что мне не очень понравилось -- это, то что заказчик не будет знать, что  получит, пока это  не получит

Это почему? Поподробней, пожалуйста. Сколь мне известно, такое возможно лишь в случае, когда заказчик сам не знает, чего хочет получить.

Вот что мне не нравится в XP, так это неприменимость понятия "сопровождение" к разработанным системам. Но не ко всяким, а к тем, которые работают 7х24 с краткими техническими перерывами или используют общие хранилища данных. Не могу я, например, БД предприятия "рефакторить" при появлении новых требований к системе - это гигантские риски положить всю систему и остановить работу всего предприятия. Часто даже не риски а гарантированные последствия, поскольку экземпляры desktop-приложений раскиданы по разным рабочим местам, и одномоментно обновить их весьма проблематично, а разные версии умеют работать лишь с соответствующими им версиями БД.

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

[Артем]

Случай когда заказчик всё время сидит рядом с программистом -- это идеальный случай. У нас так не бывает (к сожалению).

а насчет XP, первое (и, пожалуй, основное) что мне не очень понравилось -- это, то что заказчик не будет знать, что  получит, пока это  не получит

Это почему? Поподробней, пожалуйста. Сколь мне известно, такое возможно лишь в случае, когда заказчик сам не знает, чего хочет получить.

До сих пор у нас заказчик узнавал о том, что он получит из ТЗ. Но даже фразу "ввести число от 1 до 100" можно реализовать очень различными способами (начиная от ввода в "EditBox" и заканчивая рисованием числа мышкой как в paint).

 Согласен, есть тех. поректы и/или экскизные, но они у нас получаются настолько объемными и сложными, что даже разработчики этих документов с трудом в них ориентируются, а уж заказчик и подавно => заказчик их не читает (а если читает, то не осознает) => заказчик ориентируется только на ТЗ.

А в ТЗ, например, не всякий сценарий "впихнешь", не говоря уж о цвете "четвертой во втором ряду круглой кнопки".

А хотелось бы, чтобы заказчик (ну, и как побочный эффект -- порграммист ) до начала кодирования в деталях знал что получит, а не так "программа которая делает то-то и то-то".


 

[Антон (LogRus)]

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