Yurtaev
Python JavaScript UnitTest Только сейчас осознал что питон меня извратил до того что я не понимаю как правильно тестировать код с приватными методами, особенно в js когда просто критически необходимо скрывать внутри объекта "пароли" и критические методы от внешнего мира.
kb
Python UnitTest Что ж, первое улучшение по сравнению с библиотекой mock готово — теперь @patch передаёт моки в виде одного единго key-value-параметра bitbucket.org (смотреть надо на TestPatch)

но это еще не основная соль которую хотелось бы сделать. И да, от реализации даже этой фигни у меня головные боли (вот она, реализация bitbucket.org )
Kxepal
Python ? UnitTest интересно, а как тестами гарантированно описать race condition без брутфорса? или для этого выделять отдельный скрипт, который параллельно может/будет измерять производительность в агрессивной среде?
kb
Python UnitTest Пришла в голову прикольная идея — когда функц. тестов станет слишком много — запускать из них некоторое n-ное количество (можно по времени ограничить) рандомно. Рулетка получится :)
kb
Python UnitTest Таки начинаю писать длинную простыню про юнит-тестирование в питоне. Еще главного не тронул, а уже несколько страниц. Отстой :( Всегда оно так.
kb
UnitTest I hope that by now most developers agree that global state should be treated like GOTO.
Интересно, а знают ли вообще молодые девелоперы (совсем молодые, в смысле) нынче о GOTO? Пора переставать ссылаться на GOTO, а то скоро люди понимать перестанут.
demiazz
Python UnitTest Че та я не догоню. Можно протестить, вызывает ли функция исключение. А как протестировать то, что функция исключение не вызывает? О_о
kb
JavaScript UnitTest Ну, зато профит от выбора QUnit — его популярность. Хоть интерфейс вылизали относительно прикольно, мне в некоторых местах даже нравится. Вот пример: dl.dropbox.com
Jan-Itor
tdd UnitTest Личный опыт разработки библиотеки с покрытием unit тестами. На момент начала работы, я располагал подробной UML диаграммой, которая долго обсуждалась и корректировалась, в итоге unit тесты ни разу не вынудили изменить класс для того, чтобы он стал проще тестируем. Перед началом работы обнаружили, что в команде 3 разных взгляда на то, как писать тесты, в итоге пришли к соглашению по написанию тестов к классу. Красные полоски до implementation и зелёные после поднимают боевой дух. А вот когда вносишь исправление ошибки (в одну строчку), не пойманной тестами, и ради этого нужно написать ещё тесты в гораздо большее количество строк — боевой дух падает. Ближе к релизу поведение класса претерпевало изменения, а его интерфейс почти не изменялся, в итоге куча unit тестов, тестирующих специфичные ситуации, отправлялась в корзину (может я плохо их писал, а может тесты действительно выступают в таких случаях тяжелым грузом, пока не решил). Любые изменения класса при слабой связанности и взаимодействии через события могут привести к устареванию большого числа unit тестов, а это без внимания не должно оставаться. Порой тесты в полтора раза или больше превышают размеры тестируемого класса, а уверенности в том, что они покрыли все ситуации и баги, у меня никогда нет. Успешный тест не говорит о стабильности работы метода в приложении. Ни разу не встретил в статьях про unit тесты напоминание о том, что с затратами на их написание и поддержку прийдётся считаться а ведь вопрос о преимуществах использования unit тестирования стаёт более остро. Были случаи, когда я исправлял неработающий тест по работающему методу :) и мне за них стыдно. Конкретно в этом случае выгоды от моей реализации tdd не очевидны, в отличии от проблем этой реализации. Списывая на плохую реализацию буду практиковать дальше.
kb
Python UnitTest Нет, все же, я не понимаю, как можно не любить модуль unittest (и искать другие приблуды). Да, у него куча self.assertEquals и проч методов вместо одного assert, но зато он благодаря этому умеет показывать diff'ы по структурам данных (или по строкам, когда надо). Не очень наглядный, но все равно отлично читаемый пример: paste.pocoo.org
kb
Python UnitTest Все-таки то ли в питоне чего-то не хватает, то ли еще чего. Короче вот хочется сделать свои миксины, один для "тест с монгой", который self.db делает, другой "тест с репозиториями", который с фс чего-то мутит и тоже в self кладет. А не получится, потому что в двух классах не сделать setUpClass (короче как с конструкторами не получится).

Хотя вот пока писал это понял, что все усложнил и надо не выпендриваться и все настраивать всегда в одном классе да и всё.
rion
Python UnitTest столкнулся со странной фичей. модуль с юниттестом не может проимпортить модули с моим кодом(not found) если рядом есть другие модули с юниттестами.
чёэтавообще такое ? как только оставляю только один модуль, сразу начинает работать
Gard
testing бредни agile UnitTest xUnit Вот есть такая технология. Все вокруг говорят, что это очень Agile, что без тестирования код мёртв и т.д. И воде бы логично, что код надо тестировать, да и код, который гонят какую-то функцию или класс на подготовленных данных почти всегда пишется.... Но как же неудобно всё это оформлять в тесты. Не лень писать тестирующий код. Лень писать окружение для этого кода. Ведь если задуматься, то со времён когда Бек сотоварищи описали концепцию xUnit ничего вобще не изменилось. В итоге у нас есть несколько подходов один неудобнее другого. Начну, с xUnit. Чтобы начать его использовать надо подключить внешнюю библиотеку (линк+хедер), написать тестирующий класс, написать отдельное приложение либо define переключатель в своём меине который будет всё это тестировать. Зашибис. Причём для 90% случаев все вышеперечисленные шаги абсолютно одинаковы. Очень хочется поставить это всё на автомат в IDE.
Чтож добрые дяди из MS подумали и сделали интеграцию UnitTest с MSVS. И вродебы теперь тесты писать легко и быстро.... но для .NET. Конечно можно пробрасывать unmanaged код чтобы потестировать.... но теряются все плюсы. Вобще хочется чтобы тесты были сильно привязаны к методу/процедуре которую они тестируют. Чтобы можно было не только go to header/definition но и go to Test.
Следующий шаг попытались сделать в питоньих тестах. PyTest кажется. Тест помещается сразу под объявлением метода в комментарии. Только чтобы протестировать метод со всех сторон надо написать более 4 тестов обычно + часто нагрузочные, которые могут быть из нескольких строк. В итоге получается километровый комментарий, что в купе с каким-нибудь автодокументирующим стилем комментариев создаст комментариев гораздо больше чем кода. Программирование превратится в сплошной скроллинг и не дай бог понадобится что-то подправить на месте в редакторе без схлопывания участков кода.
Так и сидим. UnitTest это хорошо. это agile, это модно. НО АБСОЛЮТНО неудобно. Поэтому пусть тесты пишут вновь принимаемые на работу. Заодно с кодом познакомятся.... а мы попишем новые фичи.
yzh44yzh
IDEA Flexmojos UnitTest Вот засада, опять тесты не запускаются. Нету module/target/compile_for_tests.xml Вроде бы IDEA должна сама сгенерировать этот файл, но не генерирует :(

Сперва подумал что это из-за того, что проект настроен на форк @develar. Но нифига — переключил версию flexmojos-maven-plugin на стандартную, сделал mvn clean install, сделал реимпорт мавеновского проекта в IDEA, и все равно конфиг для тестов не генерится :(
Gard
C++ tdd msvs2010 UnitTest В новой студии теперь можно писать юнит тесты на основе встроенного фреймворка для проекта на С++. Однако чуда не случилось и тестовый проект создаётся как C++/CLI приложние, причём почему-то по умолчанию с флагом cli:save, что запрещает указатели и все "небезопасные" функции. Теперь непонятно что удобнее: делать отдельный проект под внешний cppUnit или наблюдать всё под студией, но немного через задницу....