Рубрика «юнит-тестирование»

в 8:00, , рубрики: python, база данных, Блог компании Selectel, Программирование, тестирование, Тестирование IT-систем, юнит-тестирование
Транзакционное юнит-тестирование приложений с БД - 1

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

В этой статье я хочу провести обзор разных способов юнит-тестирования приложения с БД и рассказать о способе, который я не видел в русскоязычном сегменте интернета. Статья будет посвящена Python 3, pytest и ORM-фреймворку SQLAlchemy, но методы переносимы на другие инструменты.
Читать полностью »

в 7:00, , рубрики: tdd, автоматическое тестирование, Анализ и проектирование систем, Программирование, Проектирование и рефакторинг, Тестирование IT-систем, юнит-тестирование, юнит-тесты

Эта статья является переводом материала «TDD: What went wrong or did it?».

В сфере разработки программного обеспечения уже давно хвалят Test Driven Development (TDD, разработка через тестирование). Однако в последнее время было сказано много резких слов в адрес TDD, поскольку его обвиняют в плохом проектировании программного обеспечения и невыполнении многих своих обещаний. Кульминацией этой тенденции стал пост Дэвида Хайнемайера Ханссона «TDD is dead. Long live testing.» (TDD мертв. Да здравствует тестирование).

Читать полностью »

в 12:52, , рубрики: C, c++, embedded, KEIL, tdd, unit-testing, велосипедостроение, программирование микроконтроллеров, юнит-тестирование, юнит-тесты

КПДВ

Не утихают споры о том, нужны ли юнит-тесты вообще, а если нужны — то как именно их писать. Сначала писать код или сначала писать тесты? Допустимо ли нарушать инкапсуляцию при тестировании или же можно трогать только публичное API? Сколько процентов кода должно быть покрыто тестами?

Тестирование во встраиваемых системах тоже порождает немало споров. Точки зрения разнятся от "покрытие должно быть 100% + нужны испытательные стенды" до "какие еще тесты, я программу написал — значит все работает".

Я не хочу начинать холивар и вооще стараюсь придерживаться некоего разумного баланса. Поэтому для начала предлагаю рассмотреть самые "низко висящие" плоды, которые позволяет сорвать юнит-тестирование применительно к embedded-разработке.

Читать полностью »

в 13:51, , рубрики: .net, C#, dodopizza, dodopizzaengineering, dsl, unit-testing, Блог компании Dodo Pizza Engineering, Программирование, юнит-тестирование

Как часто бывало так, что написав рабочий юнит-тест, ты смотришь на его код, а он… плохой? И ты такой думаешь: «Это же тест, оставлю так…». Нет, %username%, так оставлять не надо. Тесты — это значимая часть системы, которая обеспечивает поддерживаемость кода, и очень важно, чтобы эта часть также была поддерживаемой. К несчастью, у нас не так много способов обеспечить это (не будем же мы писать тесты на тесты), но парочка всё-таки есть.

Волшебная фея для юнит-тестов: DSL в C# - 1

Читать полностью »

в 7:00, , рубрики: DRY, java, KISS, smell, Блог компании Яндекс, браузеры, разработка мобильных приложений, Разработка под android, Тестирование мобильных приложений, тесты, типичные ошибки, юнит-тестирование, юнит-тесты

Если освоить небольшой список типичных ошибок, возникающих при написании юнит-тестов, то можно даже полюбить писать их. Сегодня руководитель группы разработки Яндекс.Браузера для Android Константин kzaikin Заикин поделится с читателями Хабра своим опытом.

— У меня доклад практический. Надеюсь, он вам всем принесет пользу — и тем, кто юнит-тесты уже пишет, и тем, кто только думает писать, и тем, кто пробует, и у кого не получилось.Читать полностью »

в 18:32, , рубрики: javascript, mocha, node.js, nodejs, Sinon, покрытие кода, Тестирование IT-систем, Тестирование веб-сервисов, юнит-тестирование, юнит-тесты

На днях я буду делать внутренний доклад, на котором расскажу нашим разработчикам про неприятные ошибки, которые могут возникнуть при написании юнит тестов. Самые неприятные с моей точки зрения ошибки — когда тесты проходят, но при этом делают это настолько некорректно, что лучше бы не проходили. И я решил поделиться примерами таких ошибок со всеми. Наверняка ещё что-нибудь подскажете из этой области. Примеры написаны для Node.JS и Mocha, но в целом эти ошибки справедливы и для любой другой экосистемы.

Чтобы было интереснее, часть из них оформлена в виде проблемного кода и спойлера, открыв который, вы увидите, в чём была проблема. Так что рекомендую сначала смотреть на код, находить в нём ошибку, а затем открывать спойлер. Решения проблем указано не будет — предлагаю самим подумать над ним. Просто потому, что я ленивый. Порядок списка не имеет глубокого смысла — просто это очерёдность, в которой я вспоминал про всякие реальные проблемы, которые доводили нас до кровавых слёз. Наверняка многие вещи покажется вам очевидными — но даже опытные разработчики могут случайно написать такой код.

Читать полностью »

в 13:50, , рубрики: Android разработка, coding style, SDK, trycatch, weakreference, Блог компании Яндекс, мобильная верстка, разработка мобильных приложений, Разработка под android, репозитории, советы начинающим, советы разработчикам, юнит-тестирование

Уже очень скоро завершится набор в Школу мобильной разработки, которая традиционно пройдет в Москве. Упор в ней будет сделан на практические занятия — командные мини-хакатоны, в которых помимо написания кода нужно будет принимать решения, разбираться с возникшими спорными вопросами и заниматься долгосрочным планированием. Помогать студентам — каждой команде индивидуально — будут ребята из Яндекса. Более подробно о предстоящей школе можно почитать здесь. Мы закончим принимать заявки 6 мая в 23:59 по московскому времени, а пока ещё есть время на выполнение заданий, мы решили разобрать прошлогодний вариант. Вы узнаете, какие ошибки часто допускают начинающие разработчики и чему следует уделить внимание при написании кода вашего первого приложения.

Советы по созданию приложений к окончанию набора в Школу мобильной разработки Яндекса - 1

Традиционно задание построено так, чтобы мы могли обратить внимание на разные аспекты разработки. К ним относится архитектура приложения, стабильность, производительность, верстка, удобство использования. Все составляющие одинаково важны: даже идеально причесанный и разложенный на слои код с большой вероятностью не пройдет отбор, если возникнут проблемы в интерфейсе или падения в процессе выполнения базовых пользовательских сценариев. Универсального рецепта приготовления идеального приложения, которое гарантированно пройдёт отбор, нет. Есть множество подходов к разработке и разные варианты построения архитектуры, но одна из составляющих успеха — позитивные пользовательские ощущения. Продукт должен создавать впечатление законченности, независимо от того, сколько в нем полезной функциональности, экранов или элементов.
Читать полностью »

в 7:14, , рубрики: chrome, headless browser, javascript, mocha, nightwatch, phantomjs, Puppeteer, selenium, Блог компании Яндекс, интеграционное тестирование, интерфейсы, Тестирование веб-сервисов, юнит-тестирование

Чтобы непрерывно улучшать большие клиентские интерфейсы, нужна мощная система автотестов. Разработчик Яндекса Дмитрий Андриянов dima117 кое-что про это знает — пару месяцев назад он поделился своим опытом на Я.Субботнике в Нижнем Новгороде.

— Сегодня я расскажу, как мы в Директе пишем модульные тесты на веб-интерфейс. Мы в целом посмотрим, чем тесты на интерфейс отличаются от других тестов. Рассмотрим два подхода к написанию тестов: с помощью Selenium и с помощью Headless-браузеров. И в конце покажу инструмент, который мы написали в Директе для запуска тестов в Headless Chrome.
Читать полностью »

в 6:57, , рубрики: tdd, test-driven development, unit test, Блог компании Everyday Tools, тестирование, Тестирование веб-сервисов, Тестирование игр, Тестирование мобильных приложений, юнит-тестирование, юнит-тесты

Забавно, как всё меняется. Пятнадцать лет я свято придерживался принципов TDD (разработка через тестирование, или, как её раньше называли, подход test-first) или уж по крайней мере того взгляда, что разработчикам следует писать юнит-тесты. Но в последнее время я всё чаще говорю не «Это нужно затестить», а «Зачем вы писали этот тест?».

Трагедия стопроцентного покрытия кода - 1

Читать полностью »

в 10:35, , рубрики: legacy, баг, Блог компании PVS-Studio, отладка, программные ошибки, Промышленное программирование, статический анализатор, Тестирование IT-систем, юнит-тестирование

11 февраля 1991 года Patriot Project Office получил израильские данные о дефекте в ракетной системе Patriot. Они нашли, что если система работает 8 часов, она начинает мазать на 20%. Они прикинули, что после 20 часов работы система начинает промахиваться настолько, что перестанет быть способной захватывать, отслеживать и поражать баллистические ракеты. Американские военные не приняли во внимание всю важность открытия, заявив, что система предназначена для портативных и краткосрочных защитных операций и что никто никогда не будет использовать систему больше 8 часов.

16 февраля был выпущен Bug Fix, но чтобы его внедрить во все единицы боевой техники, требовалось время, ибо война.

21 февраля военные выпускают указание, что система не должна работать «долго». Военные не уточнили сколько длится «долго».

25 февраля в Дахране (Саудовская Аравия) в казарму в гости к американцам прилетела баллистичекая ракета "керосинка" (она же Р-17, она же Scud). 28 убито 96 ранено, потому что ЗРК «Патриот» промахнулся из-за программной ошибки.

26 февраля Bug Fix был доставлен в Дахран.

«Керосинка» против «Патриотов»: как американские военные программисты научились правильно округлять - 1

Читать полностью »

12
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js