to post messages and comments.

Попробовал поиспользовать pgtap для TDD и
описания как должно работать. Весьма результативно.
В результате нашел несколько граничных случаев, которые до этого не видел в упор.
Будем продолжать.

tdd ?

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

Обмазать аппу тестами — отличная идея! Думал я полтора часа назад, да вот незадача:
../bin/python2 manage.py test reportapp
....
django.core.exceptions.ImproperlyConfigured: App with label reportapp could not be found
Как это понимать?!
Гугель говорит: запили аппу в INSTALLED_APPS. Логично, но безрезультатно.
Покопался в коде жанго-тестера. Нашёл! Оно так падает, если в каталоге аппы нет models.py. Главное — всё информативно и логично.

Как и догадывался, размер спек в строках кода покрывает код исходного кода как бык овцу — четыре раза, и ещё одно попугайское крылышко. Готовлю морду тапком и объяснения в стиле — "зато все модели поведения проверены!" Ну и фигу в кармане не забываю.

"няня, я у них..жпг" — замокал класс Time, метод now, возвращаю из него stub(:strftime => "some-value"), ок. И всё бы хорошо, но, внезапно, из этого stub-овского объекта вызывается to_i. Какого, спрашивается, рожна?

tdd

Интересно, что идея разработки, ведомой тестами, прозвучала еще в 1968 году (http://www.higherorderlogic.com/2011/10/test-first-development-1968/). Вот только ее либо не услышали, либо не поняли. Печально ...

Личный опыт разработки библиотеки с покрытием unit тестами. На момент начала работы, я располагал подробной UML диаграммой, которая долго обсуждалась и корректировалась, в итоге unit тесты ни разу не вынудили изменить класс для того, чтобы он стал проще тестируем. Перед началом работы обнаружили, что в команде 3 разных взгляда на то, как писать тесты, в итоге пришли к соглашению по написанию тестов к классу. Красные полоски до implementation и зелёные после поднимают боевой дух. А вот когда вносишь исправление ошибки (в одну строчку), не пойманной тестами, и ради этого нужно написать ещё тесты в гораздо большее количество строк — боевой дух падает. Ближе к релизу поведение класса претерпевало изменения, а его интерфейс почти не изменялся, в итоге куча unit тестов, тестирующих специфичные ситуации, отправлялась в корзину (может я плохо их писал, а может тесты действительно выступают в таких случаях тяжелым грузом, пока не решил). Любые изменения класса при слабой связанности и взаимодействии через события могут привести к устареванию большого числа unit тестов, а это без внимания не должно оставаться. Порой тесты в полтора раза или больше превышают размеры тестируемого класса, а уверенности в том, что они покрыли все ситуации и баги, у меня никогда нет. Успешный тест не говорит о стабильности работы метода в приложении. Ни разу не встретил в статьях про unit тесты напоминание о том, что с затратами на их написание и поддержку прийдётся считаться а ведь вопрос о преимуществах использования unit тестирования стаёт более остро. Были случаи, когда я исправлял неработающий тест по работающему методу :) и мне за них стыдно. Конкретно в этом случае выгоды от моей реализации tdd не очевидны, в отличии от проблем этой реализации. Списывая на плохую реализацию буду практиковать дальше.

мене кажется, что у каждого программиста когда-то наступает этот день:
Today is a momentous day — first day of new year. Today I am going to start a new life. I am going to stop eating a greasy food, start attending a fitness club and ... today I am going to test programs I am writing.

Boost.Test driven development or my New Year resolution
boost.org

tdd

красный-зеленый-красный-зеленый. Клева. Никаких трейсов не нужно писать для отладки, не нужно целиком комилировать и запускать весь проект для той же цели. Быстро :)

Тема POCO с eager/lazy loading, способов достижения persistence ignorance, а также тестируемости решений на EF 4 раскрыта. Сравниваются методы тестирования на основе фейков и моков. 
Как видно из заголовка, статья на английском.
Testability and Entity Framework 4.0 (http://msdn.microsoft.com/en-us/ff714955.aspx)

tdd

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

tdd

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

В новой студии теперь можно писать юнит тесты на основе встроенного фреймворка для проекта на С++. Однако чуда не случилось и тестовый проект создаётся как C++/CLI приложние, причём почему-то по умолчанию с флагом cli:save, что запрещает указатели и все "небезопасные" функции. Теперь непонятно что удобнее: делать отдельный проект под внешний cppUnit или наблюдать всё под студией, но немного через задницу....

*архитектура *проектирование *ПО
Около полугода назад, мой коллега предложил немного подработать, сделав перевод статьи для очень уважаемого ресурса. Я выбрал три статьи:
1. LXC: Kонтейнерные утилиты Linux
2. Эволюционирующая архитектура и непредсказуемое проектирование: Исследование архитектуры и дизайна
3. Эволюционирующая архитектура и непредсказуемое проектирование: Проектирование через тестирование, Часть 1
Статьи 1, 2, прошедшие отменную редактуру, такую не стыдно и похвалить (я, например, не изменял надписи на рисунках), уже доподлинно известно, что были приняты и ссылки ведут на публикации. Третья ещё находится на редактуре, как я полагаю.

Деньги же я получил только за одну статью, которая в списке под номером 1.
Своему коллеге я склонен доверять и в то, что он мог их присвоить я не верю.
Каюсь, сам не без изъяна, так как задержал перевод примерно на месяц.
Но ведь можно было как-то отреагировать... мда...
Ну да, ладно, то что деньги за проделанную работу до меня не дошли уже неважно, но зато я теперь обладаю моральным правом опубликовать свои старания. Может кому-то и пригодиться, читайте на здоровье.
Хотел опубликовать на Хабре, но там меня заминусовали ))
wwarlock.blogspot.com

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