Тестовая база данных создается минуты 3. Блин, как же это скучно и тупо, особенно когда фиксишь какой-то мелкий баг. И главное не лечится
Только сейчас осознал что питон меня извратил до того что я не понимаю как правильно тестировать код с приватными методами, особенно в js когда просто критически необходимо скрывать внутри объекта "пароли" и критические методы от внешнего мира.
Что ж, первое улучшение по сравнению с библиотекой mock готово — теперь @patch передаёт моки в виде одного единго key-value-параметра bitbucket.org (смотреть надо на TestPatch)
но это еще не основная соль которую хотелось бы сделать. И да, от реализации даже этой фигни у меня головные боли (вот она, реализация bitbucket.org )
интересно, а как тестами гарантированно описать race condition без брутфорса? или для этого выделять отдельный скрипт, который параллельно может/будет измерять производительность в агрессивной среде?
Хоть какую-то из моих просьб исполнили: paste.pocoo.org
Пришла в голову прикольная идея — когда функц. тестов станет слишком много — запускать из них некоторое n-ное количество (можно по времени ограничить) рандомно. Рулетка получится :)
Собрался духом и альфа-версию выпустил. Покритикуйте кому не лень, буду доделывать. redhotchilipython.com
Спасибо.
А вот это pyvideo.org очень сильный дядька, по крайней мере видно, что зрит в корень.
Таки начинаю писать длинную простыню про юнит-тестирование в питоне. Еще главного не тронул, а уже несколько страниц. Отстой :( Всегда оно так.
О, как-то упустил voidspace.org.uk
ох что-то я разошелся code.google.com code.google.com code.google.com
ок, теперь можно делать .rv вместо наболевшего .return_value paste.pocoo.org
маленькая, но полезная утилита. сократит тонны клавиатуры paste.pocoo.org
I hope that by now most developers agree that global state should be treated like GOTO.
Интересно, а знают ли вообще молодые девелоперы (совсем молодые, в смысле) нынче о GOTO? Пора переставать ссылаться на GOTO, а то скоро люди понимать перестанут.
Правильные вещи говорят googletesting.blogspot.com
Че та я не догоню. Можно протестить, вызывает ли функция исключение. А как протестировать то, что функция исключение не вызывает? О_о
Ну, зато профит от выбора QUnit — его популярность. Хоть интерфейс вылизали относительно прикольно, мне в некоторых местах даже нравится. Вот пример: dl.dropbox.com
Личный опыт разработки библиотеки с покрытием unit тестами. На момент начала работы, я располагал подробной UML диаграммой, которая долго обсуждалась и корректировалась, в итоге unit тесты ни разу не вынудили изменить класс для того, чтобы он стал проще тестируем. Перед началом работы обнаружили, что в команде 3 разных взгляда на то, как писать тесты, в итоге пришли к соглашению по написанию тестов к классу. Красные полоски до implementation и зелёные после поднимают боевой дух. А вот когда вносишь исправление ошибки (в одну строчку), не пойманной тестами, и ради этого нужно написать ещё тесты в гораздо большее количество строк — боевой дух падает. Ближе к релизу поведение класса претерпевало изменения, а его интерфейс почти не изменялся, в итоге куча unit тестов, тестирующих специфичные ситуации, отправлялась в корзину (может я плохо их писал, а может тесты действительно выступают в таких случаях тяжелым грузом, пока не решил). Любые изменения класса при слабой связанности и взаимодействии через события могут привести к устареванию большого числа unit тестов, а это без внимания не должно оставаться. Порой тесты в полтора раза или больше превышают размеры тестируемого класса, а уверенности в том, что они покрыли все ситуации и баги, у меня никогда нет. Успешный тест не говорит о стабильности работы метода в приложении. Ни разу не встретил в статьях про unit тесты напоминание о том, что с затратами на их написание и поддержку прийдётся считаться а ведь вопрос о преимуществах использования unit тестирования стаёт более остро. Были случаи, когда я исправлял неработающий тест по работающему методу :) и мне за них стыдно. Конкретно в этом случае выгоды от моей реализации tdd не очевидны, в отличии от проблем этой реализации. Списывая на плохую реализацию буду практиковать дальше.
Нет, все же, я не понимаю, как можно не любить модуль unittest (и искать другие приблуды). Да, у него куча self.assertEquals и проч методов вместо одного assert, но зато он благодаря этому умеет показывать diff'ы по структурам данных (или по строкам, когда надо). Не очень наглядный, но все равно отлично читаемый пример: paste.pocoo.org
Все-таки то ли в питоне чего-то не хватает, то ли еще чего. Короче вот хочется сделать свои миксины, один для "тест с монгой", который self.db делает, другой "тест с репозиториями", который с фс чего-то мутит и тоже в self кладет. А не получится, потому что в двух классах не сделать setUpClass (короче как с конструкторами не получится).
Хотя вот пока писал это понял, что все усложнил и надо не выпендриваться и все настраивать всегда в одном классе да и всё.
столкнулся со странной фичей. модуль с юниттестом не может проимпортить модули с моим кодом(not found) если рядом есть другие модули с юниттестами.
чёэтавообще такое ? как только оставляю только один модуль, сразу начинает работать
Вот есть такая технология. Все вокруг говорят, что это очень Agile, что без тестирования код мёртв и т.д. И воде бы логично, что код надо тестировать, да и код, который гонят какую-то функцию или класс на подготовленных данных почти всегда пишется.... Но как же неудобно всё это оформлять в тесты. Не лень писать тестирующий код. Лень писать окружение для этого кода. Ведь если задуматься, то со времён когда Бек сотоварищи описали концепцию xUnit ничего вобще не изменилось. В итоге у нас есть несколько подходов один неудобнее другого. Начну, с xUnit. Чтобы начать его использовать надо подключить внешнюю библиотеку (линк+хедер), написать тестирующий класс, написать отдельное приложение либо define переключатель в своём меине который будет всё это тестировать. Зашибис. Причём для 90% случаев все вышеперечисленные шаги абсолютно одинаковы. Очень хочется поставить это всё на автомат в IDE.
Чтож добрые дяди из MS подумали и сделали интеграцию UnitTest с MSVS. И вродебы теперь тесты писать легко и быстро.... но для .NET. Конечно можно пробрасывать unmanaged код чтобы потестировать.... но теряются все плюсы. Вобще хочется чтобы тесты были сильно привязаны к методу/процедуре которую они тестируют. Чтобы можно было не только go to header/definition но и go to Test.
Следующий шаг попытались сделать в питоньих тестах. PyTest кажется. Тест помещается сразу под объявлением метода в комментарии. Только чтобы протестировать метод со всех сторон надо написать более 4 тестов обычно + часто нагрузочные, которые могут быть из нескольких строк. В итоге получается километровый комментарий, что в купе с каким-нибудь автодокументирующим стилем комментариев создаст комментариев гораздо больше чем кода. Программирование превратится в сплошной скроллинг и не дай бог понадобится что-то подправить на месте в редакторе без схлопывания участков кода.
Так и сидим. UnitTest это хорошо. это agile, это модно. НО АБСОЛЮТНО неудобно. Поэтому пусть тесты пишут вновь принимаемые на работу. Заодно с кодом познакомятся.... а мы попишем новые фичи.
Да уж, конечно JUnit ( scalatest.org ) смотрится не так клево как FunSuite ( scalatest.org ) или FeatureSpec ( scalatest.org )
Но имеющиеся тесты гораздо проще переписать на JUnit, чем разбираться с этой экзотикой. К тому же это мейнстрим, его надо знать )
Вот засада, опять тесты не запускаются. Нету module/target/compile_for_tests.xml Вроде бы IDEA должна сама сгенерировать этот файл, но не генерирует :(
Сперва подумал что это из-за того, что проект настроен на форк @develar. Но нифига — переключил версию flexmojos-maven-plugin на стандартную, сделал mvn clean install, сделал реимпорт мавеновского проекта в IDEA, и все равно конфиг для тестов не генерится :(
кто юзает во флекс разработке? Кто какой фреймворк юзает? flexmojos поддерживают 6 вариантов, надо выбрать. docs.sonatype.org
покамест наиболее подходящим кажется FlexUnit4
В новой студии теперь можно писать юнит тесты на основе встроенного фреймворка для проекта на С++. Однако чуда не случилось и тестовый проект создаётся как C++/CLI приложние, причём почему-то по умолчанию с флагом cli:save, что запрещает указатели и все "небезопасные" функции. Теперь непонятно что удобнее: делать отдельный проект под внешний cppUnit или наблюдать всё под студией, но немного через задницу....