Сегодня выпущен первый релиз CodeRush for Roslyn (далее CRR).
Теперь можно купить лицензию CRR. Есть 2 варианта покупки:
Через год можно либо продлить лицензию, либо продолжить работу без обновлений.
Читать полностью »
Каждый день в мире создаётся новый код. Много кода. Какая-то часть этого кода может быть полезна вам. Может снизить затраты на разработку или сэкономить ваше время. Но чтобы воспользоваться кодом, в нём необходимо разобраться, поэтому ленивые разработчики больше читают, чем пишут. Быстрое понимание как работает код – это ценный навык, который приобретается с годами практики. В этой статье мы расскажем как CodeRush for Roslyn (далее CRR) помогает быстрее читать код даже тем, кто еще не овладел в совершенстве этим навыком. Статья будет интересна хакерам и ленивым разработчикам.
Мы выпускаем новый продукт — CodeRush for Roslyn, далее CRR. Уже более 10 лет у нас есть другой продукт, который называется просто CodeRush, или CodeRush Classic, сокращенно CRC. Главное отличие CRR от CRC в том, что Roslyn версия использует парсинг и языковые сервисы встроенные в Visual Studio. CRR полностью написан с нуля, поэтому он быстрый и легкий, и уже содержит все необходимое для эффективной работы.
В этой статье расскажу о поддержке тестовых фреймворков в CRR. Почти во всех примерах будет использован проект https://github.com/dewe/Money. Этот проект использует NUnit framework, но мы так же поддерживаем xUniut, MSpec, MS Test Framework. Все рассмотренные ниже практики работают одинаково вне зависимости от того, какой тестовый фреймворк вы используете.
Читать полностью »
Как-то при подготовке одного из докладов про разработку плагинов для Gradle встала задача — как свои поделия потестировать. Без тестов вообще жить плохо, а когда твой код реально запускается в отдельном процессе и подавно, потому что хочется дебага, хочется быстрого запуска и не хочется писать миллион example-ов, чтобы протестировать все возможные кейсы. Под катом сравнение нескольких способов тестирования, которые мы успели попробовать.
Функциональное тестирование интерфейса (GUI) приложений — задача очень важная, нужная, но не всегда тривиальная. Основной вопрос тут: как сэмулировать работу пользователя? Простого, рядового пользователя, которому придется непосредственно изо дня в день работать с вашим софтом.
Казалось бы, причем здесь распознавание текстов?
Читать полностью »
Доброго времени суток!
Хочу собрать всю самую необходимую теорию по тестирвоанию, которую спрашивают на собеседованиях у trainee, junior и немножко middle. Собственно, я собрал уже не мало. Цель сего поста в том, чтобы сообща добавить упущенное и исправить/перефразировать/добавить/сделатьЧтоТоЕщё с тем, что уже есть, чтобы стало хорошо и можно было взять всё это и повторить перед очередным собеседованием про всяк случай. Вообщем, коллеги, прошу под кат, кому почерпнуть что-то новое, кому систематизировать старое, а кому внести свою лепту.
Всё ниже перечисленное ны выдумано мной лично, а взято с разных источников, где мне лично формулировка и определение понравилось больше. В конце перечислены все источники.
В теме: определение тестирования, качество, верификация / валидация, цели, этапы, тест план, пункты тест плана, тест дизайн, техники тест дизайна, traceability matrix, tets case, чек-лист, дефект, error/deffect/failure, баг репорт, severity vs priority, уровни тестирования, виды / типы, подходы к интеграционному тестированию, принципы тестирования, статическое и динамическое тестирование, исследовательское / ad-hoc тестирование, требования, жизненный цикл бага, стадии разработки ПО, decision table, qa/qc/test engineer, диаграмма связей.
Читать полностью »
Привет!
Пару месяцев назад я писал пост, о том как научить webpack для spa.
С того момента инструмент шагнул вперед и оброс дополнительным количеством плагинов, а так же примерами конфигураций.
В этой статье хочу поделиться опытом смешивания гремучей смеси webpack + jasmine + chai + karma.
Читать полностью »
Как говорится: «Запретный плод сладок», так и у меня. Попробовав однажды писать тесты на RSpec, хочется иметь декларативный BDD DSL в каждом языке. Вот например JavaScript, имеет аналоги mocha.js, jasmine.js, etc. Но нет, мало. Хочется не просто всяких describe-ов или it-ов а еще и ленивых переменных, я имею в виду subject и let.
На первый взгляд глупо! Внутренний голос кричит «Зачем?», а совесть в ответ: «Чистый код — это важно! Ну а простые тесты — вообще мега важно!».
Вот так и родилась библиотека для mochajs, которая позволяет создавать ленивые переменные (aka let) и `subject`.
Для тех кто понимает о чем я и уже напрягся засветился от радости, милости просим на Github.
Всем остальным, а в особенности скептикам предлагаю заглянуть под cut.
Читать полностью »
Все мы не раз слышали о test-first — философии разработки, которая призывает писать тесты раньше кода. Уверен, что любой, кто пытался применять этот метод на практике, сталкивался с тем, что у него просто не получается написать тест до функции (обычно в этом случае просто игнорируют эту проблему и локально нарушают test-first). Я считаю, что причина подобных провалов фундаментальна, и попытаюсь показать почему.
Для начала следует уточнить, что здесь и далее я буду говорить про тестирование функции в широком смысле слова как тестирование некоторой условной примитивной единицы кода. Оставим в стороне вопрос, какую подобную единицу нужно тестировать (например, метод или класс), на дальнейший ход рассуждения эти детали влияния не окажут. Я буду использовать выражение «тестирование функции» в этом смысле на протяжении всей статьи.
Вам может показаться, что индустрия давно разобралась со всеми проблемами, связанными с test-first, и причина всех возможных провалов лишь в том, что мы как разработчики не обладаем достаточной квалификацией для успешного применения нужных техник, а вовсе не в каких-то фундаментальных проблемах. Увы, здесь и там разные программисты задают одни и те же вопросы, как именно делать test-first, и получают порой невразумительные ответы. Думаю, без преувеличения можно сказать, что комьюнити по всему миру что-то подозревает, но многое остается недоговоренным.
Читать полностью »
Прежде чем говорить об оптимизации производительности баз данных, нужно пояснить, каким показателем эта производительность измеряется, — тем более что в памяти многих людей, связанных с базами данных, еще жив показатель «время отклика», который многие привыкли считать универсальным мерилом производительности СУБД.
