DISCLAIMER: вы попались на clickbait. Очевидно, что TDD нельзя назвать ошибочным, но… Всегда есть какое-то но.
Рубрика «unit-testing» - 2
TDD ошибочно?
2018-04-11 в 15:01, admin, рубрики: javascript, js tools, tdd, testing tools, tools, unit-testing, Программирование, управление проектамиЗаблуждения об автоматическом тестировании
2018-04-09 в 8:15, admin, рубрики: $mol, $mol_test, javascript, testing, TypeScript, unit-testing, Программирование, тестирование, Тестирование IT-систем, Тестирование веб-сервисов, тестирование по, тестирование приложенийЗдравствуйте, меня зовут Дмитрий Карловский и это продолжение традиционной рубрики "Почему мы так не любим писать тесты?". Короткий ответ: потому, что получаемые от них бонусы не перевешивают затрачиваемых усилий. Если это так, значит мы делаем что-то не правильно. Давайте разберёмся что же могло пойти не так..
Данная заметка выросла из главы "Заблуждения" лонгрида "Концепции автоматического тестирования", посредством дополнения новыми заблужениями и аргументами.
Концепции автоматического тестирования
2018-03-18 в 18:53, admin, рубрики: $mol, $mol_test, javascript, testing, TypeScript, unit-testing, Программирование, тестирование, Тестирование веб-сервисов, тестирование по, тестирование приложенийЗдравствуйте, меня зовут Дмитрий Карловский и у меня, к сожалению, нет времени писать большую статью, но очень хочется поделиться некоторыми идеями. Поэтому позвольте потестировать на вас небольшую заметку о программировании. Речь сегодня пойдёт об автоматическом тестировании:
- Зачем мы пишем тесты?
- Какие бывают тесты?
- Как мы пишем тесты?
- Как их стоит писать?
- Почему модульные тесты — это плохо?
Unit-тестирование скриншотами: преодолеваем звуковой барьер. Расшифровка доклада
2018-03-14 в 10:05, admin, рубрики: components, gif, Git, javascript, jest, PNG, Puppeteer, React, teamcity, unit-testing, Блог компании Avito, Программирование, Разработка веб-сайтов, Тестирование веб-сервисовТестировать регресс верстки скриншотами модно, этим никого не удивишь. Мы давно хотели внедрить этот вид тестирования у себя. Всё время смущали вопросы простоты поддержки и применения, но в большей степени — пропускная способность решений. Хотелось, чтобы это было что-то простое в использовании и быстрое в работе. Готовые решения не подошли, и мы взялись делать свое.
Под катом расскажем, что из этого вышло, какие задачи решали, и как мы добились того, чтобы тестирование скриншотами практически не влияло на общее время прохождения тестов. Этот пост — расшифровка доклада, который прозвучал на HolyJS 2017 Moscow. Видео можно посмотреть по ссылке, а почитать и посмотреть слайды — далее.
10 интересных нововведений в JUnit 5
2017-09-12 в 13:32, admin, рубрики: development, java, junit, unit-testing, Проектирование и рефакторинг, Тестирование IT-системВ минувшее воскресенье Sam Brannen анонсировал выход JUnit 5! Ура!
Поздравляю всех участников @JUnitTeam а также всех, кто использует JUnit в своей работе! Давайте посмотрим, что же нам приготовили в этом релизе.Читать полностью »
ReactJS — мое понимание тестирования
2017-07-01 в 20:11, admin, рубрики: react.js, ReactJS, testing, unit-testing, Тестирование веб-сервисовКак мог бы сказать мой босс, всем рок. Поскольку я ничего умнее не придумал, на этом и остановимся.
Собственно сей материальчик не обязательно претендует на то, чтобы чему-то научить других. Возможно, я соберу достаточно хорошего в комментах, чтобы вместо этого научиться самому ) Тут будет описана задача, как я представляю сейчас ее решение и почему.
С реактом я работаю пару месяцев как, в основном мой бекграунд это бэк, а тут вроде как ликвидация безграмотности. Redux и прочие вспомогательные концепции в уравнение пока не введены.
Возникла задача попробовать таки сделанное небольшое приложение протестировать. Ну, всякие сервисы вполне в привычном стиле можно тестировать каким-нибудь jasmine. С компонентами сложнее: по идее тестировать принято контракты, а не реализацию, то есть тесты должны иметь вид «ткнули кнопку — приложение попыталось сделать то-то».
Ну все, завязываю со вступлением.
Читать полностью »
Про ScalaCheck. Свойства. Часть 3
2017-03-01 в 22:21, admin, рубрики: scala, scalacheck, unit-testing, Программирование, Тестирование IT-систем, функциональное программированиеЧасть 3. Свойства
В предыдущих частях мы уже успели познакомиться со свойствами и опробовать их в связке с генераторами. В этом туториале мы рассмотрим свойства подробнее. Статья состоит из двух частей: первая — техническая, в ней будет рассказано про комбинаторы свойств, а также другие возможности библиотеки ScalaCheck. Эта часть будет посвящена различным техникам тестирования.
Погружение в Robolectric
2017-02-01 в 10:42, admin, рубрики: android, robolectric, unit-testing, Блог компании e-Legion Ltd., Разработка под android, Тестирование мобильных приложенийВ мире Android-разработки всё чаще используют unit-тестирование. Проверка корректности работы отдельных модулей приложения помогает выявить и устранить ошибки в коде уже на ранних этапах. Вкупе с автоматизацией сборки, компонентными и интеграционными тестами, unit-тесты позволяют делать качественный продукт, независимо от размера вашей команды разработчиков.
Под катом расскажу о внутреннем устройстве фреймворка для unit-тестирования Android-приложений — Robolectric.
Про ScalaCheck. Генераторы (Часть 2)
2017-01-21 в 23:48, admin, рубрики: scala, scalacheck, unit-testing, Программирование, Тестирование IT-систем, функциональное программированиеЧасть 2. Генераторы
В вводной статье серии вы, надеюсь уже, успели познакомиться с генераторами. В этом туториале мы закрепим полученные знания, научимся писать собственные (в том числе рекурсивные) генераторы. Хотя он и посвящен генераторам, про свойства мы тоже не забудем. Более того, мы будем их активно использовать, демонстрируя всю мощь механизма генераторов. Рассмотрим механизм предусловий (preconditions). Возможно, более логичным было бы посвятить свойствам вторую статью серии и, возможно, это стало бы правильным решением. Однако, по моим личным наблюдениям, наибольшие трудности вызывают именно генераторы. Свойства мы рассмотрим в следующей статье.
dock: простая библиотека модульного тестирования кода на С++
2017-01-18 в 12:39, admin, рубрики: c++, c++ библиотеки, C++14, unit-testing, Unit-тестирование, Тестирование IT-системХотя и существуют уже библиотеки для юнит-тестирования кода на С++, например, Google Test или Bandit, но они написаны не мной здесь оно, на мой взгляд, как-то переусложнено, по сравнению с тем же JS. Там просто делаешь, например, npm i mocha assert --save-dev и можно приступать к написанию тестов, а здесь же нужно это сделать ручками, а в случае с gtest еще и собрать с помощью cmake ее. Bandit подключается просто, но не умеет в сериализацию результатов в какой-то формат данных, gtest это умеет, но его нужно собирать отдельно. А я не хочу выбирать "либо то, либо это". Мне было нужно сделать удобный и простой инструмент под мои задачи. Я хотел получить простую библиотеку без зависимостей, header-only, на несколько файлов, которую можно легко и быстро подключить к своему проекту, удобно внести в нее изменения (если это будет необходимо). Но, самое основное, мне хотелось получать удобные, машиночитаемые отчеты, причем не только в stdout (или xml, как в gtest), но и в любой другой формат, который я захочу. Далее под катом.