понедельник, 30 июня 2014 г.

Offtopic. Вспомнилось почему-то

Нам один из преподавателей по физхимии любил говаривать - "я вам ставлю УДОВЛЕТВОРИТЕЛЬНО. Идите и подумайте о том, что удовлетворение - это очень глубокое чувство".

Ссылка. Еще немного о формах…

http://delphi2010.ru/delphi_for_dumies/

По мне - ОЧЕНЬ жаль, что "такое приходится писать"...

Это скажем так - "понижение планки" (ИМХО).

Я ведь сам начал с "абстракных контейнеров и примесей" - http://programmingmindstream.blogspot.ru/2014/06/blog-post_8821.html

А "кончил" - "тестированием калькулятора" - http://programmingmindstream.blogspot.ru/2014/06/blog-post_10.html

И это ещё не "край", есть ещё - http://programmingmindstream.blogspot.ru/2014/06/dunit.html

"Оказывается" и "про DUnit" - "не все в курсе".

Опять "понижение планки"?

Или я "о чём-то не том пытаюсь писать".

Может быть мои темы "интересны только мне"?

Жаль тогда конечно... Что-то "не то" я последние 20-ть лет делал.

Мне казалось, что есть вещи, которые "написаны в документации" и их не нужно описывать.

И есть КОНЦЕПТУАЛЬНЫЕ вещи типа "использования эталонов" или "обработки ошибок".

Я ведь и "на истину" - не претендую и на "высокие материи" - тем более, как те же (Тепляков, Gunsmoker или Багель).

Я ведь пытаюсь писать "чисто о ремесленничестве".

Про то "как программировать проще".

Но тут мне пишут - "Я не говорю, что во всех тестах Вы тестирует активную форму калькулятора. Но с одной стороны, такие тесты у Вас есть, с другой, в тех местах где это не так, достаточно других специфичных вещей (вроде базового класса для тестов) которые акцентируют внимание не на DUnit, а на выбранной Вами архитектуре тестов, которая сильно зависит от решаемой задачи."
http://programmingmindstream.blogspot.ru/2014/06/dunit.html?showComment=1403825194432#c302980178779134556

И ведь - УМНЫЙ человек пишет.

САМ ОЧЕНЬ много УМНЫХ ВЕЩЕЙ сделавший.

"Базовый класс для теста" - это ПРАВДА СЛОЖНО? Или Я чего-то не понимаю.

Да и главное - не в АВТОРЕ цитаты дело (как раз ЕГО - я БОЛЕЕ ЧЕМ уважаю).. Похоже - МНОГИЕ НЕ ПОНИМАЮТ... Вот в чём беда..

С "автором цитаты" я уж как-нибудь "разберусь". ПОВЕРЮ, что он "пикируется", потому что ТАКОЙ умный (это комплимент), но!

Ведь и ДРУГИЕ ПИШУТ - "очень сложно"...

Не понимаю...

Мне вообще КАЗАЛОСЬ, что "тестирование калькулятора" это более чем ПРОСТО.

Где мой прокол?

Похоже - я о ЧЁМ ТО НЕ О ТОМ пишу?

И ещё - "я никого не хотел задеть".. Просто хотел СПРОСИТЬ - "где Я дурак"?

Нет ну правда...

Если "ещё понизить" планку, то окажется, что надо писать о том "что написано в доукментации или в учебниках". Или я не прав?

Или "доносить свои мысли" - это НЕ МОЁ? Или - "а были ли мысли"?

Или с "методологией" что-то всё же не так?

Ссылка. Form Events, события формы для работы с пользовательскими данными

http://www.delphinotes.ru/2013/03/form-events.html

пятница, 27 июня 2014 г.

Ссылка. 7 вещей, которые делают хорошие работодатели

http://hbr-russia.ru/upravlenie/upravlenie-personalom/p13634/#ixzz2zVhUavBy

Не буду комментировать.

Побрюзжу. О размере "конторы" и КАЧЕСТВЕ кода

http://programmingmindstream.blogspot.ru/2014/06/blog-post_2144.html?showComment=1403815635817#c5991733166570813708

Вот ПОЧЕМУ - чем БОЛЬШЕ контора или если она аффилирована с госструктурами, тем МЕНЕЕ качественный у неё софт?

У нас в России по крайней мере.

И что с этим делать? "Устраивать майдан"? Или есть "более вменяемые" способы борьбы с "проблемами качества" и "равнодушием разработчиков и службы поддержки".

Есть Success-story борьбы "с равнодушием"?

И вообще - РАБОТАЮТ ЛИ "рыночные механизмы"?

Ну откажусь я от Beeline... Ну что МТС лучше что ли? Это к примеру...

Про "госуслуги" - так ВООБЩЕ МОЛЧУ...

И ещё...

Вот у МФЦ есть РЕГЛАМЕНТ - "10-ть мин на посетителя". КОМУ "жаловаться" если РЕГЛАМЕНТ НЕ ВЫПОЛНЯЕТСЯ?

Или это всё глупости?

Или проблема в "зарплате разработчиков"?

четверг, 26 июня 2014 г.

Смешно. По мотивам...

Смешно. По мотивам...

Задавал тут вопрос - http://programmingmindstream.blogspot.ru/2014/06/blog-post_18.html

Знаете что я выяснил в последующее время?

Это то, что aPipe - НАДО защищать.

Но!

Не НА СЕРВЕРЕ.

А НА КЛИЕНТЕ!

Интересно как?

Ссылка. События формы. Лабораторные Delphi, C++ (5)

http://alexanderbondar.blogspot.ru/2014/06/9-delphi-c-5.html

Промолчу.

Я ОБЫЧНО - "читаю код"...

Кстати. Есть вопрос. Про DUnit

Кстати. Есть вопрос. Про DUnit.

Есть "мысли" написать "цикл" - "Что такое DUnit и как оно устроено изнутри".

1. Как запускаются тесты.
2. Что такое Startup/Teardown.
3. Какая связь с JUnit и CUnit.
4. Как связаны тесты и published-методы.
5. Как делать тесты без published-методов.
6. Как делать парметризованные тесты.
7. Что такое AwaitableException.
8. Как ловить утечки памяти.
9. Что такое ITest и ITestSuite.
10. Какие есть расширения и надстройки для DUnit.
11. Что такое GUITestRunner и ConsoleTestRunner. И есть ли альтернативы.
12. Что же делать с DUnit и FM.
13. Как делать анти-тесты.

etc.

Эта тема интересна?

Мне то лично про это "писать неинтересно", потому что - "код читаю".. Но "оказывается" - "есть вопросы"...

Ссылка. Парсер математических выражений 2

http://delphikingdom.ru/asp/viewitem.asp?catalogid=1448

И ещё "о пользе тестов"...

Вдогонку к - http://programmingmindstream.blogspot.ru/2014/06/blog-post_25.html

У меня вот есть "кодогенерация"... Не "совсем доделанная"...

Но! ЗАТО ПОКРЫТАЯ тестами...

Я когда к ней возвращаюсь - то СРАЗУ понимаю "что и как"...

Благодаря тестам...

среда, 25 июня 2014 г.

И ещё о тестах. Буду занудой

Сегодня пытался подать документы на загранпаспорт. Нового образца.

В МФЦ на Неделина. По району Кунцево.

И надо же - МНЕ ТАК "НЕ ПОВЕЗЛО".

ТАМ включили новую "систему учёта и электронной очереди".

И РАБОТА встала.

В СОСЕДНЕМ окне по "Можайскому АО" - приняли 40-к человек, а в нашем - 10-ть.

За ДВА ЧАСА.

Что говорят сотрудники?

У нас НОВАЯ СИСТЕМА - "она НЕ РАБОТАЕТ".

Вот так блин...

А если бы ПРОГРАММИСТЫ (и их менеджеры) ОЗАБОТИЛИСЬ БЫ тестированием, то такого - СКОРЕЕ ВСЕГО не произошло бы.

НЕ "у нас временной прессинг и цейтнот", а "СДЕЛАТЬ по-человечески". С ТЕСТАМИ. Протестировать САМИМ, а не НА "реальных пользователях".

Я - наивный конечно.

Но! Может быть в этом что-то есть?

Не "выкатывать" систему "как есть", а ПРОТЕСТИРОВАТЬ.

Может БЫТЬ и в России станет жить "лучше".

Не ТАК, как говорит Собянин - "в Москве стало жить лучше", а РЕАЛЬНО ЛУЧШЕ.

Я наивный. Я знаю...

P.S. Ну и ещё "о цейтноте" - http://programmingmindstream.blogspot.ru/2014/06/blog-post_8413.html - это скажем так - "в противовес написанному".

Коротко. О пользе тестов

Не устаю повторять, что ТЕСТЫ это в ОДНУ из ПЕРВЫХ голов - ПРИМЕР использования кода.

Как?

Пример "из жизни".

Вот положим - я занимаюсь "НИР".

Написал код. Написал тесты.

Всё как-то работает.

Потом - "перебросили на более ответственный участок работ".

Потом вернулся. Ещё пописал. Код и тесты.

И опять "как-то работает".

Потом опять "ушёл". А в памяти-то - "всё стирается".

И уже и "не помню" - что делал и как.

Потом "вдруг" ОПЯТЬ "понадобилось".

Вернулся. Посмотрел на код и тесты. И ВСЁ ПОНЯТНО.

Мысль понятна?

А если "вернулся", но "не я", а ДРУГОЙ.

Тоже - посмотрел на код "мало что понял", посмотрел на тесты - и "всё понял".

Мысль понятна?

Это - "пример из жизни". Не одиночный.

Тестируем калькулятор №7. Сравнение чисел с плавающей запятой. Детальнее об архитектуре тестов

Оглавление всей серии постов о тестировании калькулятора.
Нарисовав диаграмму классов к прошлой главе, я заметил что у меня есть класс TRandomPlusTest который я не видел в GUI DUnit'a.

вторник, 24 июня 2014 г.

Ссылка. О ТЗ, цейтноте и "позабывании"

http://18delphi.blogspot.ru/2013/04/blog-post.html

Ссылка. Как я исправляю ошибки

http://18delphi.blogspot.ru/2013/03/blog-post_54.html

Коротко. И ещё "о тестах"

Обработка ошибок - http://programmingmindstream.blogspot.ru/2014/06/622.html
Рандомные тесты - http://programmingmindstream.blogspot.ru/2014/06/62.html

Эти темы - СВЯЗАНЫ!

Как?

"Спросите меня".

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

И ешё - ТЕСТЫ - это ИНФРАСТРУКТУРА РАЗРАБОТКИ. В ПЕРВУЮ очередь... А уж В ПОСЛЕДНЮЮ - средство измерения "регресса".

Offtopic. Да простят меня "программисты"

http://bdsa.ru/

воскресенье, 22 июня 2014 г.

Ссылка. Манускрипт Войнича. Маньчжурский кандидат

http://habrahabr.ru/post/186952/

суббота, 21 июня 2014 г.

Ещё немного о тестировании

http://programmingmindstream.blogspot.com/2014/06/blog-post_10.html

Мне тут резонно заметили, что мол очень много трудозатрат на тестирование такой простой функциональности.

Есть такое дело.

Я сам об этом думал, когда "ввязывался в это дело".

Маленький пример. Не показательный.

И столько уже тестовых классов.

А будет ещё больше.

Но!

На то это и "учебный пример". На основе которого хотелось показать многие аспекты тестирования.

Как то:

1. Настройка инфраструктуры. И её поддержание.
2. Тестирование GUI.
3. Тестирование логики.
4. Регрессионное тестирование.
5. Применение эталонов входа/выхода.
6. "Скриптование" тестов как "экстраполяция применения эталонов".
7. Связь тестов, функционала и ТЗ.
8. Зависимость тестов от клиентской среды.

Мне кажется, что в некотором роде - "у нас получается".

Хотелось бы опять коснуться "темы эталонов".

Хотя пример и "учебный" и "надуманный", но по-моему он УЖЕ проиллюстрировал несколько вещей таких как:

1. Тестирование логики.
2. Регрессионное тестирование.
3. Обработка ошибок и определение детерминированности поведения системы даже на неверных данных.

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

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

Как говориться - "следите за обновлениями".

Да и ОТДЕЛЬНО я постараюсь разобрать такую вещь как "каталоги абстрактных тестов" для РАЗНЫХ, но однотипных проектов.

пятница, 20 июня 2014 г.

Ссылка.Отношения классов — от UML к коду

http://habrahabr.ru/post/150041/

Тестируем калькулятор № 6.2.2. Приложение. UML диаграмма классов тестирования

Оглавление всей серии постов о тестировании калькулятора.

Git шпаргалка.

Допустим мы сделали несколько коммитов в ветке DC-2.

0 шаг. Делаем Pull из удаленного репозитория.
1 шаг. Делаем Rebase to HEAD к ветке Developing

Смешно

http://forum.ru-board.com/topic.cgi?forum=33&topic=13825&start=1260

Но про "захват" - интересно...

Ссылка. Выводим конкретные атомарные контейнеры из абстрактных

http://18delphi.blogspot.ru/2013/07/blog-post_8789.html

О "методике" написания статей

Критически пересматривал свой блог.

И вот что хочу написать:

Любая стать должна строиться так:

1. Что решаем?

2. Как решаем?

3. Чего достигли?

4. Выводы на будущее.

Так?

Хоть одна моя "статья" или "пост" этому соответствует?

Готов выслушать "нелицеприятную критику".

Например по поводу цикла - http://programmingmindstream.blogspot.ru/2014/06/blog-post_10.html

четверг, 19 июня 2014 г.

Ссылка. Стереотип (UML)

http://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B5%D1%80%D0%B5%D0%BE%D1%82%D0%B8%D0%BF_(UML)

Про скрипты, итераторы и обработку исключений. Черновик

Чужой текст:

"

Особенности работы с перебором объектов (итераторами).

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

Стоило мне написать про ночи без звонков. Как это сразу и случилось. Заказчик прислал такую вот картинку:

В общем, я конечно же не учел деления на ноль.
На мой удивленный вопрос - "А Вы знаете что на 0 делить нельзя ?"
Клиент заявил что - "Необходимо что бы калькулятор писал "Деление на 0" в ответе".

Про Exception'ы. Коротко. Скажем так - "анонс"

Можно написать так:

 try
  ...
 except
  on E: SomeException do
   ...
 end;

А можно вот так:

 try
  ...
 except
  on E: Exception do
   if E.ClassType = SomeException then
   ...
 end;

А можно вообще так:

 try
  ...
 except
  on E: Exception do
   if E.ClassName = 'SomeException' then
   ...
 end;

Что "правильнее" и что "лучше"?

Вопрос - НЕ ПРАЗДНЫЙ...

Особенно вариант с E.ClassType = SomeException...

Почему?

Потому что далеко не ВСЕГДА "разработчик библиотеки" может "угадать" какие исключения "пользователь" унаследует.

Особенно при наличии виртуальности.

Пояснения нужны?

P.S. Это скажем так - "провокационный пост".

среда, 18 июня 2014 г.

ЧУЖОЙ ПОСТ. Что мотивирует инженера. Ссылку не нашёл, ПОЭТОМУ публикую текст

Что мотивирует инженера

Горящие глаза программистов, азартный рефакторинг, коммиты наперегонки и вопрос «Что бы ещё покрыть тестами?» — это не сказка. Так бывает.

Постановка проблемы

Как мотивировать разработчиков?

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

Неудивительно, что в иерархии ценностей программистов на первом месте стоит признание, а не доход — с которым, как известно, у них всё в порядке.

Не отсюда ли корни такого феномена как Open Source? Сервер, на котором крутится этот сайт, язык, на котором написан этот сайт, его база данных и движок — всё это бесплатно доступный труд сотен энтузиастов. Трудно себе представить учителя или юриста, который будет до красных глаз сидеть у монитора, чтобы с гордостью выкатить свой шедевр в свободный доступ благодарному человечеству.

Из популярной книги по психологии программистов «Как пасти котов»: «Любой сотрудник жаждет признания своей деятельности, хочет ощущать весомость своего вклада в общее дело».

Однако складывается ощущение, что этот факт часто упускается из виду, хотя именно он помог бы отделу кадров резвее находит таланты, инженерам обеспечил бы огонёк в работе, а начальству — повышенный показатель ROI.

Существующие варианты решения

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

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

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

Ну серьёзно, есть ли компании, у которых в Scrum входит ритуал обнимашек («потребность в принадлежности и любви»), выбивание имени разработчиков на граните («потребность в признании»), курсы фен-шуй или хотя бы тренинги по рефакторингу («эстетические потребности») или шанс реализовать свой проект в рамках компании («самореализация»). Ведь даже Google закрыл тему с 20% времени на свои проекты!.

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

Том ДеМарко в книге «Deadline» пишет: «Когда разработчики не чувствуют поддержки и признания начальства, они редко создают сильные сплоченные команды». А сильная, «кристаллизированная» команда может творить чудеса.

Предлагаемый подход

Есть много способов повышения престижа. Неважно, кто вы, — директор компании или тимлид разработчиков, — как только вы осознаете мощь этого подхода, нужный вариант сам придёт к вам в качестве озарения.

Вот лишь несколько примеров, чтобы вы почувствовали вкус этой идеи.

Сначала история. Вы — программист, толковый, в этой компании уже довольно давно. И вот на общей кухне, пока вы машинально делаете себе очередной кофе, у вас завязывается разговор с кем-то из заказчиков фирмы. И вот этот бизнесмен говорит: «Ааа, так это ты тот Сергей, который сделал подсистему Х? Мне про это рассказывал ваш директор! Круто, круто». Приятно? Что-то подсказывает, что в этот день ваш код будет компилиться быстрее.

Признание заслуг и достижений — самый простой способ.

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

Господи, ну отличились ваши программисты — ну так напишите им неожиданные и хорошие рекомендации в LinkedIn. Предложите им при случае оплатить любую книжку на Амазоне, «потому что я знаю, что вы педалили 3 ночи напролёт». Уважительно упомяните при работниках других отделов, сколько денег они заработали-сэкономили фирме за счёт своей последней разработки. Не надо просто покупать им пиццу — они это сами могут; лучше покажите им, что вы их любите.

Дальше можно устроить системную конкуренцию за лидерство. Это когда каждую неделю команда сама определяет, кто Мистер Потужность =). Для этого надо определить две вещи: как считать очки и какой приз.

Очки за улучшение кода можно считать автоматически — есть плагин CI Game для Jenkins: плюс балл за каждый коммит, приведение к Code Standard, увеличение покрытия тестами, удаление копипасты, и т.д.

Каждую пятницу смотрят, кто набрал больше всего очков. Есть победитель!

Если команда географически распределённая, то придумывается нематериальный приз. Например, победителя всю неделю называть «сэр».

Если все в одном месте, то проще — придумайте неформальный приоритет. Выбор офисной музыки всю неделю (NB: если у вас есть офисная музыка, чтение книги «Peopleware» откроет вам много нового). Возможность выбирать имя итерации. Право сидеть на StandUp-митинге. Индульгенция на 10-минутное опоздание утром.

А лучше всего — купите всамделишный кубок и сделайте на нём гравировку типа «Kick-ass of the week». Пусть этот кубок стоит на столе победителя всю неделю. У кого он продержится дольше всех?

Плюсов тут не счесть! Остальные работники офиса втягиваются и начинают выяснять детали, мол, «а за что дают? а что такое юнит-тесты?». Вышестоящее начальство замечает усердие. Приходящие заказчики и инвесторы довольно улыбаются: одно дело — невидимый магический код, другое — спортивные состязания и осязамые трофеи; есть что обсудить. Пусть страна знает своих героев.

В общем, это короткая, позитивная и объединяющая всех церемония. А Том ДеМарко в «Peopleware» писал: «Организации нуждаются в церемониях. [...] Такие собрания не тратят впустую ничьё время. Они отвечают на реально существующую потребность в признании. Они закрепляют членство в группе — его важность и ценность».

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

В качестве примера можно привести графа Витте, выпускника одесского физмата ещё при царе. Витте был пропагандистом практической пользы математического склада ума. «По легенде, С. Витте на глазах императора вступил в конфликт с царскими адъютантами, доказывая, что нельзя использовать два мощных грузовых паровоза с целью разгона царского поезда до высоких скоростей. Александр III убедился в правоте С. Витте после крушения царского поезда в 1888.» (Википедия).

Ещё благодаря его переговорным способностям — «Сахалин наш» =) Если уж царь не побоялся назначить ботана министром, то и вам стоит посмотреть на свой IT-отдел свежим взглядом.

В качестве заключения: в спорт-трекере Endomondo есть такая функция — «авто-подбадриватель». Включите авто-подбадриватель в своей команде, и вы удивитесь результатам.

Вопрос к читающим и думающим

Вот код:

procedure TSomeClass.DoReply(aPipe: TDataPipe);
begin
 Self.CriticalSection.Enter;
 try
  aPipe.WriteDateTime(Now);
 finally
  Self.CriticalSection.Leave;
 end;//try..finally
end;TSomeClass.DoReply

Что в этом коде защищается критической секцией? И зачем?

aPipe? А ЗАЧЕМ? Если он подаётся СНАРУЖИ. И если уж его ЗАЩИЩАТЬ, то почему "тот кто его подаёт сверху" - НЕ ОЗАДАЧИЛСЯ защитой?

Или Now? А его-то ЗАЧЕМ?

Или что-то другое я не вижу?

Помогите пожалуйста.

Ссылка. Новый класс Exception в Delphi 2009 и выше

http://www.gunsmoker.ru/2010/04/exception-delphi-2009.html

Что мне лично было там интересно? Это - вложенные исключения.

Ещё немного про TDD

Читаю тут обсуждение вот к этому посту:

http://habrahabr.ru/post/116514/

Например вот:

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

И, имхо, TDD (именно тдд а не юнит тесты) не всегда возможно. Есть класс задач где тесты не могут быть инициатором разработки и дизайна. Все равно в начале нужно продумать архитектуру а потом наращивать мясо.

Вопросы к ТДД гурам:
1. Что вы делаете с тестами если поменялась архитектура? Удаляете, переписываете? Вариант ответа: «ТДД дает сразу правильную архитектуру» не канает.
2. Как тестировать сложное окружение? Тестировать только элементарные блоки? или писать кучу моков?"

И создаётся впечатление, что либо люди РЕАЛЬНО не понимают, либо ими "движет банальная лень".

Мол зачем писать тесты? Это мол "напрасная трата времени".

Только есть ОДНА ВЕЩЬ - которую я ВСЁ ПЫТАЮСЬ донести - "тесты это не средство поиска ошибок" (http://habrahabr.ru/post/149903/).

Тесты это средство ПРОВЕРЯТЬ ДЕТЕРМИНИРОВАННОСТЬ кода.

Тесты это - ИНФРАСТРУКТУРА. Которая "ведёт за собой разработку". Именно ПОЭТОМУ в TDD присутствует слово Driven.

Можно начать разработку с теста, а закончить "привязыванием функционала к GUI", а не наоборот. Я писал тут - http://programmingmindstream.blogspot.ru/2014/06/blog-post_16.html

А если слова "привязывание к GUI" заменить на слова "ожидание смежников", то по-моему становится несколько понятно, что "это не просто трата времени", а ещё и ИНФРАСТРУКТУРА. Помогающая разработке.

Но!

КРОМЕ ЭТОГО - есть ещё одна вещь - когда тесты "набирают мясо", то случается такой момент, что "тестовый функционал" оказывается настолько МОЩНЫМ, что он начинает "плавно перетекать" из тестов в "бизнес-логику". И ТАКИМ ОБРАЗОМ он начинает "подстёгивать" процесс разработки.

И код написанный "для тестов" становится ПОЛНОЦЕННЫМ кодом бизнес-логики.

Как?

Про это я думаю в скором времени написать. В нашей серии "Тестирование калькулятора".

Текущее оглавление серии тут - http://programmingmindstream.blogspot.ru/2014/06/blog-post_10.html.

понедельник, 16 июня 2014 г.

Не устаю делиться "классикой". Джоэл. "Назад, к основам"

http://russian.joelonsoftware.com/Articles/BacktoBasics.html

"Забуримся поглубже в пирог. Динамические библиотеки? Объекты? Функции? Нет! Глубже! В какой-то момент мы увидим строки программного кода.
Ещё глубже. Сегодня я хочу поговорить о процессорах. Маленький кусочек кремния, который байты двигает. Представим себе, что мы учимся программировать. Отложим знания об управлении проектами и языках высокого уровня и вернёмся к основам, заложенным ещё фон Нейманом. Забудем на минуту о J2EE. Подумаем о Байтах."

Черновик. Разбираю тут тестирование клиент-серверного взаимодействия по TCP/IP

Разбираю тут тестирование клиент-серверного взаимодействия по TCP/IP.

На работе.

Там много всяких тонкостей. И "приёмов работы".

В частности - mocking. "Исключение" передающих звеньев. Dependency Injection. Изоляция слоёв и маршалинга между ними.

И как "не размазывать" части логики, которые являются "взаимоответными" типа SaveToPipe и LoadFromPipe по "взаимонесвязанным" проектным классам. И как вообще обойтись без оперирования "бизнес-логикой" понятием "коннеции" (Pipe).

Надо будет об этих моментах написать подробнее.

Особенно о приёмах того как на "завязываться на mocking", а исключать "передающие звенья". Если мы "уверены", что эти звенья "и так работают". Или протестировали их ОТДЕЛЬНО.

И о том - как это ведёт к детерминированности и "тестируемости" архитектуры.

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

Единственный момент - очень сложно придумать "синтетический пример" простой для понимания и не связанный с работой.

Буду думать.

P.S. "Тестирование калькулятора" что ли сделать клиент-серверным :-) Чтобы "морда" в одном приложении, а "бизнес-логика" - в другом... Для ПРИМЕРА... Есть в этой шутке доля шутки...

P.P.S. И кстати - что бы вы посоветовали бы взамен "голого TCP/IP"? DCOM/CORBA/Soap?

Ссылка. Просто почитайте комментарии к коммитам

https://bitbucket.org/ingword/lulinproject/commits/branch/DC-7_Chapter_6.3

Просто почитайте комментарии к коммитам.

Я там попытался показать "ход мыслей" при рефакторинге тестов. А также "стандартную инструкцию" для добавления новой функциональности.

Ещё раз повторюсь.

Инструкция примерно такая:

1. Добавляем тест новой функциональности (именно ТЕСТ, а не функциональность). В тесте пишем Assert(false, 'Not Implemented'). Что мы делаем на этом шаге? Мы решаем вопрос - ГДЕ мы будем тестировать (настраиваем ИНФРАСТРУКТУРУ). Тест - не проходит.
2. Добавляем "заготовку" функциональности. В ней пишем Assert(false, 'Not Implemented'). Связываем тест с данной функциональностью. Что мы делаем на этом шаге? Мы решаем вопрос - ЧТО мы будем тестировать (определяем ПРОТОТИП функциональности). Тест - не проходит.
3. Наполняем "заготовку" реальной функциональностью. Тест - проходит. (Когда вся функциональность реализована).
4. Прогоняем ДРУГИЕ тесты. Они ДОЛЖНЫ проходить. Если они НЕ ПРОХОДЯТ, то разбираемся с ними и с затронутой функциональностью.
5. Связываем функциональность с GUI (именно НА ЭТОМ шаге, в чём и ПРЕЛЕСТЬ подхода). Проверяем как это работает.
6. Прогоняем ДРУГИЕ тесты. Они ДОЛЖНЫ проходить. Если они НЕ ПРОХОДЯТ, то разбираемся с ними и с затронутой функциональностью.
7. Пишем тест GUI (при необходимости).
8. Прогоняем ДРУГИЕ тесты. Они ДОЛЖНЫ проходить. Если они НЕ ПРОХОДЯТ, то разбираемся с ними и с затронутой функциональностью.

Как-то так...

Текст к этим коммитам и отдельная глава про "Тестирование калькулятора" - будут позже.

Ссылка. Delphi sorcery

http://delphisorcery.blogspot.ru/

пятница, 13 июня 2014 г.

Из сети. Попалось тут. "План тестирования двери"

Мне автор не известен - посему публикую без ссылки и указания авторства.

Скажем так - "в каждой шутке есть доля шутки".

А теперь цитата:

"

h5.План тестирования двери

1. Функциональные проверки.
1.1. Проверить, что дверь открывается.
1.2. Проверить, что дверь закрывается.
1.3. Попытаться закрыть уже закрытую дверь.
1.4. Попытаться открыть уже открытую дверь.

2. GUI (интерфейс пользователя)
2.1. Проверить табличку на двери.
2.2. Проверить покраску двери.
2.3. Проверить наличие дверной ручки.

3. Permissions.
3.1. Проверить, что правильным ключом дверь открывается.
3.2. Проверить, что неправильным ключом дверь не открывается.
3.3. Проверить, что закрытую на ключ дверь нельзя открыть.
3.4. Проверить, что не закрытую на ключ дверь можно открыть без ключа.
3.4. Позвонить в дверь. Если там никого нет, дверь не должна открыться сама.
3.5. Постучать в дверь. Если там кто-то есть и он спросит «кто?», ответить «Полиция». Дверь должна открыться.

4. Stress/Loading
4.1. Открывайте и закрывайте дверь со скоростью 120 циклов в минуту
4.2. Открывайте и закрывайте дверь со скоростью 6 раз в минуту на протяжении 48 часов.
4.3. Стучите в дверь с частотой 1200 стуков в минуту.
4.4. Стучите в дверь с частотой 10 раз в минуту на протяжении 24 часов.
4.5. Открывайте и закрывайте дверь ключом на протяжении 12 часов.

5. End to end
5.1. Постучать в дверь. Позвонить в звонок. Открыть ключом. Открыть дверь. Закрыть дверь. Закрыть ключом. Прочитать табличку на двери.

6. Usability
6.1. Проверить, что ручка двери помещается в ладонь.
6.2. Проверить, что ручка находится именно на двери, а не на соседней стене на высоте 20 см.
6.3. Проверить, что высота двери больше человеческого роста
6.4. Проверить, что усилие для поворота ключа в двери в пределах допустимого

* Проверить функциональность двери при температуре 38, 45 и -15 градусов Цельсия.
* Проверить функциональность двери при различной относительной влажности, днем и ночью, в июле и с декабре.
* Проверить, что пол и социальное происхождение открывающего никак не влияют на результаты.

Добавка:
1. Начать с использования двери одним человеком. Увеличивать количество пользователей с шагом 5 человек в 5 сек.
Увеличивать нагрузку, пока дверь не сломается.
2. Проверка документации к двери — инструкции пользователя, технического паспорта..
3. Проверка сердцебиения и давления открывающего. Действия по открыванию-закрыванию не должны пожирать все ресурсы пользователя.
4. Проверить влияние функционирования двери на появление трещин в стене.
5. White box tests: проверить волокна древесного полотна на параллельность.

Проверить отдельные элементы (классы) на предмет избыточности (а может там 6 замочных скважин).
Проверка алгоритма запирания двери.

Критика плана:
Отсутствуют проверки на стрессовость (удар ногой или головой)
Отсутствуют проверки на крепеж двери к косяку
Отсутствуют проверки соседнего модуля — косяка (зазоры между ним и дверью)
Отсутствуют проверки между дверью и полом.
"

Что сказать? План - хорош. Хотя и избыточен, если говорить "на все случаи жизни"...

Ни о чём. Просто "заметка"

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

Оба кандидата бы на мой взгляд - очень хороши.

Один дал более чем подробные ответы на "стандартный вопросник" и даже сопроводил их "маленькими UML-диаграммами".

Но знаете, что больше всего поразило? Это даже не то, что он изложил всё на 8-ми листах.

А то, что он их ВДУМЧИВО пронумеровал :-)

Вот думаю - он сильно зануден или "зануден настолько насколько нужно"? :-)

Ссылка. Тестирование — это не поиск ошибок!

http://habrahabr.ru/post/149903/

От СЕБЯ - "ТЕСТИРОВАНИЕ это в ПЕРВУЮ очередь ИЗМЕРЕНИЕ детерминированности кода".

А теперь:

Цитата:

"Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?

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

Что такое поиск ошибок?

Я тестирую продукт. Моя задача — завести как можно больше багов. Оно и логично! Заводить баги тестировщику всегда приятно, это видимый измеримый результат работы, И чем их больше, тем больше меня ценят как тестировщика.

Какие области я буду тестировать в таком случае? В первую очередь, самые нестабильные. Зачастую они нестабильны потому, что менее приоритетны, но это неважно, значительно важнее количество багов.

Что будет, если я столкнусь со сложновоспроизводимым багом? ROI на его исследование считается в голове очень быстро. Зачем мне с ним возиться, если я за это же время смогу завести 3 менее критичных, зато простых в заведении?

Какие тесты я буду проводить в первую очередь? Конено, самые нестандартные. Ввести в поле логина «Войну и мир», поделить на ноль, вставить в профиль фотографию в формате .exe.

Скажу по секрету — иногда на собеседованиях тестировщики в ответ на просьбу «протеструйте калькулятор» перечисляют интересные и дельные тесты, но в числе первых тридцати нет теста «проверить сложение» и другие базовые операции.

Именно так выглядит поиск ошибок — не имеющий ничего общего с тестированием."

Ссылка. Тестируем калькулятор

http://software-testing.ru/forum/index.php?/topic/22729-testiruem-kalkuljator/

Цитата:

"Всем привет! Я только начинаю постигать азы данного направления и меня очень интересует, как правильно написать Smoke test и Critical Past test для калькулятора.
Краткие требования:
* элементы интерфейса - кнопки 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, +, -, *, /, ., =, С, BckSpc и поле ввода
* после старта в поле ввода отображается ноль
* поле ввода отображает 10 знаков, включая десятичную точку
* числа, содержащие больше 10 знаков, отображаются в экспоненциальной форме - 5 цифр, потом буква е, потом знак плюс или минус, потом три цифры
* нажатие цифровых кнопок приводит к стандартному результату
* арифметические операции выполняются стандартным образом - вводится первый операнд, нажимается клавиша операции, вводится второй операнд, нажимается клавиша "равно"
* если после выполнения операции нажать клавишу "равно" еще раз, то повторяется предыдущая операция с отображаемым результатом в качестве первого операнда и вторым операндом из предыдущего действия в качестве второго
* клавиша С очищает поле ввода, там отображается ноль
* клавиша BckSpc удаляет последний символ из поля ввода
* отрицательные числа нельзя ввести, но они могут возникнуть в результате операций
* обрабатываются числа от -1.79769е+308 до 1.79769е+308
Буду признателен за подробное описание. "

И ещё цитата:

"Теперь несоклько наводящих вопросов, ответив на которые, Вам станет легче выополнять задание. Рекомендую отвечать прямо тут. Ничего нет страшного, если Вы ответите неверно или неполно:

Что такое Smoke test (для ответа на этот и следующий вопросы можно использовать поиск по форуму, поиск по порталу sofrware-testing, гугл,яндекс)?
Для чего он нужен?
Как с Вашей точки зрения выглядит Smoke Test для калькулятора?
Что такое Critical Path Test?
Для чего он нужен?
Считаете ли вы приведенные требования полными?
Если да, то почему?
Если нет, то какие требования неполны и чего не хватает? Какие есть неточности?
Можно ли задавать вопросы по заданию? Какие у Вас возникли вопросы?
На кого рассчитан калькулятор? Что пользователи будут делать чаще всего?
Какие тест-кейсы Вы бы предложили для Critical Path Test?

Ссылка. Основные положения тестирования

http://testitquickly.com/2010/03/09/testing-basics-by-barancev/

Цитата:

"

Что такое тестирование

Сначала попробуем понять, чем тестирование НЕ является.

Тестирование не разработка,

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

Тем не менее, тестирование — это не деятельность по разработке программного обеспечения.

Тестирование не анализ,

и не деятельность по сбору и анализу требований.

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

Тестирование не управление,

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

Тестирование не техписательство,

однако тестировщикам приходится документировать свои тесты и свою работу.

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

Деятельность значима только тогда, когда она востребована, то есть тестировщики должны что-то производить «на экспорт». Что они делают «на экспорт»?

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

Это наивно.

Хотя частично это правда.

Но это не вся правда.

Главная деятельность тестировщиков

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

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

Но эта вещь очень значимая, и, наверное, единственная наиболее значимая составляющая деятельности тестировщиков.

Существует наука — «теория систем». В ней определяется такое понятие как «обратная связь»:

«Обратная связь» это некоторые данные, которые с выхода попадают обратно на вход, или какая-то часть данных, которые с выхода попадают обратно на вход. Эта обратная связь может быть положительной и отрицательной.

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

И та, и другая разновидности обратной связи равноценно важны.

Отрицательная обратная связь стабилизирует систему благодаря тому, что она ослабляет входной сигнал.

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

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

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

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

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

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

Синонимы термина «тестирование»

С точки зрения того, что тестирование — это предоставление отрицательной обратной связи, всемирно известная аббревиатура QA (англ. Quality Assurance — Обеспечение качества) синонимом термина «тестирование» уж совершенно точно НЕ является.

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

А вот «контроль качества» — Quality Control, можно считать в широком смысле синонимом для термина «тестирование», потому что контроль качества это и есть предоставление обратной связи в самых разных ее разновидностях, на самых разных этапах программного проекта."

четверг, 12 июня 2014 г.

Тезисы. Тесты. Как я их вижу

Список будет пополняться.

Что такое тесты?

1. Тесты это средство проверки архитектуры. (Если архитектура "тестируема", то она - "хороша").
2. Тесты это средство документации кода. (Если к куску кода написан тест, то это значит, что дан пример использования).
3. Как следствие из предыдущего пункта - тесты это средство КОММУНИКАЦИИ между разработчиками.
4. Тесты это инфраструктура разработки. (Обеспечивается возможность "рафинированных" вызовов и "специальной подготовки данных").
5. Тесты это средство выявления противоречивостей в ТЗ. (Если два или более тестов "не сходятся" одновременно, то это скорее всего проблема в ТЗ).
6. Тесты это средство проверки детерминированности кода. (Повторные запуски одинаковых тестов для детерминированного кода должны "сходиться").
7. Тесты это средство выявления регресса.
8. Тесты это средство проверки корректности логики работы.

Что такое атомарные тесты?
1. Это средство проверки корректности логики работы. (Согласно ТЗ).

Что такое тесты с эталонами?
1. Это средство проверки детерминимрованности кода.
2. Это средство выявления регресса.

Что такое с тесты псевдослучайными данными?
1. Это средство расширения тестового покрытия.

среда, 11 июня 2014 г.

Тестируем калькулятор №6.2.1. Применяем "классическое TDD"

Оглавление всей серии постов о тестировании калькулятора.

В нашей новой главе мы попробуем применить "классическое TDD" при разработке новой операции нашего калькулятора.

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