Да, мутационное тестирование это очень интересная идея для проверки качества тестов.
Для Python есть несколько библиотек, которые я смотрел:
— cosmic-ray
— mutpy
Они работают, но когда у вас много разветвленного кода — количество мутантов растет и прогон тестов начинает занимать непростительно много времени.
О мутационном тестировании я рассказывал на Pycon Siberia 2016. К сожалению, видео доклада пока нет, но организаторы обещали.
После прогона тесткейса на всех мутациях будет собран настоящий честный code coverage
С этим можно поспорить) Безусловно, после прогона тестов на мутантах и исправления тестов — ваши тесты станут лучше. Но, как мне кажется, говорить о честном coverage, все еще рано.
Основная мысль доклада, как уже говорили в комментариях — «Не надо верить тулзам, которые говорят, что тесты хорошие».
coverage.py по-дефолту покажет непокрытые строки кода и вы увидите заветные 100% покрытия, но стоит указать параметр --branch и покрытие падает, потому что вряд ли покрыты все возможные переходы. Покрыв переходы между инструкциями (этот режим считает именно переходы между statements, а не lines) получаем снова 100%.
Но получается и этим 100% верить нельзя. Вот отсюда и второстепенная мысль доклада — «А что можно сделать, что бы еще лучше оценить покрытие кода». И во второй половине доклада представлена идея покрытия кода на уровне байткода.
Что касается названия — реакция в комментах показала, что название выбрано как нельзя лучше :-)
Да, PLY, ANTLR и подобные генераторы парсеров выигривают, если вы знакомы с БНФ. Остальные варианты имеют право на жизнь, если вам необходимо быстро написать маленький простой парсер для простой грамматики.
Честно говоря, я не знал о существовании рантайма под Python в момент подготовки этого доклада.
Как вы и сказали — ANTLR это тоже генератор анализаторов, как и PLY. В докладе хотелось сравнить различные подходы к написанию парсеров и были выбраны наиболее популярные библиотеки, реализующие эти подходы.
Тогда зачем авторизация, если сервер будет проверять наш IP?
Почему бы в этом случае не попользоваться htpasswd? Не идеальный вариант — но сильно лучше чем гонять сырой пароль, по URL, который доступен из браузера.
Поломался ваш бот, хотя пару часов назад работал отлично)
И попутно посмотрел на других ботов, заинтересовался yadictbot, но вот незадача — телеграм говорит что нет такого :(
Вчера обратил внимание на грузовой турникет на Восстания. На правом поручне считыватель для обычных проездных, на левом — видимо для PayPass, прикрытый бумажкой «не работает» :)
Если не сложно, расскажите пожалуйста как обстоят дела с одной лицензией на несколько компьютеров? Имеется машинка на видне и на маке, и там и там пользуюсь PyCharm — я смогу использовать одну лицензию, или все-таки на каждую машинку надо отдельно?
Для Python есть несколько библиотек, которые я смотрел:
— cosmic-ray
— mutpy
Они работают, но когда у вас много разветвленного кода — количество мутантов растет и прогон тестов начинает занимать непростительно много времени.
О мутационном тестировании я рассказывал на Pycon Siberia 2016. К сожалению, видео доклада пока нет, но организаторы обещали.
С этим можно поспорить) Безусловно, после прогона тестов на мутантах и исправления тестов — ваши тесты станут лучше. Но, как мне кажется, говорить о честном coverage, все еще рано.
Основная мысль доклада, как уже говорили в комментариях — «Не надо верить тулзам, которые говорят, что тесты хорошие».
coverage.py по-дефолту покажет непокрытые строки кода и вы увидите заветные 100% покрытия, но стоит указать параметр --branch и покрытие падает, потому что вряд ли покрыты все возможные переходы. Покрыв переходы между инструкциями (этот режим считает именно переходы между statements, а не lines) получаем снова 100%.
Но получается и этим 100% верить нельзя. Вот отсюда и второстепенная мысль доклада — «А что можно сделать, что бы еще лучше оценить покрытие кода». И во второй половине доклада представлена идея покрытия кода на уровне байткода.
Что касается названия — реакция в комментах показала, что название выбрано как нельзя лучше :-)
Как вы и сказали — ANTLR это тоже генератор анализаторов, как и PLY. В докладе хотелось сравнить различные подходы к написанию парсеров и были выбраны наиболее популярные библиотеки, реализующие эти подходы.
Ваш вариант делает тоже самое, но выглядит странно:
Почему бы в этом случае не попользоваться htpasswd? Не идеальный вариант — но сильно лучше чем гонять сырой пароль, по URL, который доступен из браузера.
Это еще более ранняя версия
Есть же хорошее решение, которое отлично работает — https://github.com/dimka665/vk
UPD: Ниже уже говорили это… Я буду читать все комменты перед отправкой своего)
И попутно посмотрел на других ботов, заинтересовался yadictbot, но вот незадача — телеграм говорит что нет такого :(
Извините, но больно читать…
«Это обсолютно пустой холт, который дожидайется вас»
«ихнем»
[/offtop]
Если я правильно понял вашу статью — это просто веб-интерфейс для редактирования json?) Как-то не придумывается сходу хоть один вменяемый кейс
flask.pocoo.org/docs/0.10/views/#method-views-for-apis