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

ща буду смотреть по цепочке, где такое могло случиться, но вместо дебага это будут ассерты же

а когда закончу, этот тест останется жить

я понимаю.

"я хочу написать функцию, которая будет вычислять мегарезультат. Если вызвать с аргументом 0, то вернет 0, поэтому напишу такой тест. Фэйл - еще нет никакой функции. Пишу функцию, в ней pass. Фэйл - None это не 0. Заменяю на return 0, тест пройден. Но я-то знаю, если я напишу тест, что от 1 оно равено 2, то пофейлится. Пишу. Фейл. Заменяю на if arg==1: return 2; return 0

вот этот вечный пример в тдд вымараживает. "у меня функция считае x^2, поэтому я пишу if x==0 return 0, if x==1 return 1, if x==2 return 4, все тесты зелёные, потом я отдаю в тест x=3 всё падает и я наконец-таки пишу нормальный код. " Ёба, да напиши ты сразу нормально, зачем эти промежуточные итерации? ТДД придумали для дебилов, которые не могут код сразу написать, а рожают через муки, промежуточные этапы и примерные приближения?

я не против тестов вообще, но подход "test first" - для меня очень спорен.

самое время упомянуть https://hypothesis.readthedocs.org/

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

а тдд да, идеально подходит для случаев "я еще не знаю, что я там хочу, но на выходе хочу видеть вот такой результат"

а тдд да, идеально подходит для случаев "я еще не знаю, что я там хочу, но на выходе хочу видеть вот такой результат"

мне не попадались статьи про ТДД и что-то приближённое к жизни. Везде одна и таже лабуда: "а теперь убираем пачку ифов..."

Спс ребята, отличный чат, читаю вас каждый день

но к слову, после пары статей я не сильно-то и искал.

самое время упомянуть https://hypothesis.readthedocs.org/

Оно позволяет в тесты скормить кучу сгенерёных по каким-то правилам данных, но при это тесты нужно так написать, чтобы они не зависили от входных данных?

есть еще бдд

есть еще бдд

это там где тесты пишутся в свободной писменной форме?

ну тесты по разному можно писать, но подход в том что ты не конкретный метод тестишь а функционал

типа "зашел на страницу, получил ответ 200ок, увидил форму регистрации с такими то полями"

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

ну да, интеграционные тесты

бдд это тесты от поведения. А конкретная реализация может быть разной. Есть например тесты по таблицам, но обычно вспоминают про язык gerkin, который через Given-When-Then

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

для питона я использовал с этой целью behave. Есть другие реализации, но именно behave мне понравился больше других

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

ну да, это я имел в виду. Какое-то время назад про это как-то много шума было, потом поутихло. Сдох проект, или теплится ещё?

нормально

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

не особо ограничивает, но такие тесты больше интеграционные - ты не будешь писать "когда я вызываю функцию f с аргументом 5"

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

и надо адекватно создавать энвайронмент, который такое сможет обработать

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

у меня например был тест для веба, там через селениум тыркался интерфейс и была проверка openid, так пришлось писать свою минимальную реализацию опен айди

а он уже давно существует

и он читабелен для простых смертных

писать на нем простые смертные не смогут на самом деле

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

а чё бы код веб-сервисов не делать читабельными для простых смертных? ?

получится 1С

простой смертный придет в ужас от @handler(/admin) def admin: return "hello, world"

а вот When I go to '/admin' Then I see "hello, world" - это ок

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

вот я слышал про тулзу fitnesse или типа того. Там создаются таблички типа как в вики и транслируются в тесты

простой смертный зашел в вики по проекту и видит ожидаемый результат. А тулза делает проверку в точности по этой таблице

геркин для тех, кто не осилил его не сложный англиский?

Скажите вот про тесты и тдд

геркин можно и по-русски на самом деле

Как вообще врубиться, на что имеет смысл писать тесты, а на что нет? Или добиваться 100% покрытия?

геркин можно и по-русски на самом деле

в русском слова склоняются, говно получится же?

если уже есть код, который работает, нафига туда тесты?

а там целиком фразы только имеют смысл

ну .. местами дублировать

тестировать надо то, в чем ты не уверен

есть такая штука - exploratory testing кстати

если уже есть код, который работает, нафига туда тесты?

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

тебе дали код, ты его посмотрел и думаешь, что он ведет себя так-то

если уже есть код, который работает, нафига туда тесты?

перед рефакторингом. когда несколько часов две трети кишок проета переписываешь, а тесты в основном зелёные - это же оргазм, не?

пишешь тест, чтобы это проверить

ну в смысле код уже есть, а тестов еще нет. Добавлять тесты к уже написанному коду это чисто украшательство для "а у нас 100% покрытие"

ну в смысле код уже есть, а тестов еще нет. Добавлять тесты к уже написанному коду это чисто украшательство для "а у нас 100% покрытие"

++++

есть книжка working effectively with legacy code, которая на самом деле это и рассматривает - у меня есть адский код и мне надо с ним работать, но я боюсь поломать, а тестов нету

там и эксплоратори тестинг и эксплоратори рефакторинг и прочее такое рассматривается

ну в смысле код уже есть, а тестов еще нет. Добавлять тесты к уже написанному коду это чисто украшательство для "а у нас 100% покрытие"

Есть код вида shellout 'sed blah foo | grep bar' например

ну я такие конструкции без всяких тестов переписываю - например цепочка из 3 седов и 3 грепов превращается в 1 сед или 1 авк

потому что я не боюсь это сломать

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

Я недавно сломал например Не предусмотрел возврат пустой строки

bash для сильных духом.

ERROR: S client not available

bash для сильных духом.

Это перл ведь сплошной

sed от перла в читаемости недалеко ушёл, не?

ну я такие конструкции без всяких тестов переписываю - например цепочка из 3 седов и 3 грепов превращается в 1 сед или 1 авк

Чтобы стать нечитабельной? (

sed от перла в читаемости недалеко ушёл, не?

особенно, если три грепа и awk в однострочник переписывать.

нет, сед вполне ок, там нет зубодробительных конструкций

там конечно все команды однобуквенные, но их мало

с awk спутал.

Так вот, как вообще писать тесты для методов/фитнес, обрабатывающих реальные данные

Функций

ну просто бывает такое: cat file | grep 'pattern' | awk '{print $2}' | sed 's/thing/other/g'

ну как, граничные условия в первую очередь

Так вот, как вообще писать тесты для методов/фитнес, обрабатывающих реальные данные

реальные данные подменять моками?

реальные данные подменять моками?

Вот.

смотреть на код и думать - а вот сломается ли оно, если подать -1? А если -1000000?

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

Не слишком ли жирно это для многих случаев?

ну еще раз - я смотрю на функцию и мне вот с ходу понятно, как она работает - ну зачем тут тесты?

не, некоторые для 100% покрытия напишут тесты чтобы на каждую ветку

я не буду

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

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

но может быть я посмотрю на функцию и у меня возникнет вопрос "а как она себя поведет, если я подам туда 100? Должно получиться 28. О, надо ж, не упала."

есть разница между моком и стабом

стаб это "вместо сложной штуки лежит более простая"

а мок это "вместо сложной штуки лежит мой ручной мутант, у которого я всегда могу спросить, что именно с ним творила эта функция"

чё-то очень тонкая грань, кмк.

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

Я дожил до момента когда в python-чате говорят о python ))

в питоне unittest.mock содержит клевый декоратор patch, который позволяет что угодно на ходу подменить моком, вызвать функцию с параметром Х, а потом спросить у мока "ну что, тебя правда вызвали с параметром Y?"

более конкретно - "ну что, функция правда пыталась полезть в инет на урл http://google.com/?search=Vasya Pupkin"

А можно не спрашивать, и получить поведение стаба?

а делается это путем замены urllib.urlretrieve на мок.

через patch можно, да