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

Примеры использования Moq

2012-09-04 в 17:02, admin, рубрики: .net, moq, тестирование, метки: .net, moq, unit-testing

Moq – это простой и легковесный изоляционный фреймврк (Isolation Framework), который построен на основе анонимных методов и деревьев выражений. Для создания моков он использует кодогенерацию, поэтому позволяет «мокать» интерфейсы, виртуальные методы (и даже защищенные методы) и не позволяет «мокать» невиртуальные и статические методы.

ПРИМЕЧАНИЕ
На рынке существует лишь два фрейморка, позволяющих «мокать» все, что угодно. Это TypeMockIsolator и Microsoft Fakes, доступные в Visual Studio 2012 (ранее известные под названием Microsoft Moles). Эти фреймворки, в отличие от Moq, используют не кодогенерацию, а CLR Profiling API, что позволяет вклиниться практически в любой метод и создать моки/стабы даже для статических, невиртуальных или закрытых методов.
Читать полностью »

Введение во фреймворки (Часть 2)

2012-08-31 в 14:50, admin, рубрики: automation testing, testing, капитан очевидность, много букв, тестирование

Тестирование
Часть 1

Второе поколение фреймворков

Это поколение является промежуточным уровнем фреймворков автоматизированного тестирования, среди них могут быть и достаточно простые фреймворки, а могут быть и достаточно хорошо спроектированные. Подобные фреймворки должны рассматриваться в случае, когда поддержка автотестов является важным фактором. Хорошее понимание этого поколения фреймворков является важным, так как на концепциях фреймворков этого уровня основываются фреймворки третьего поколения.
К фреймворкам второго поколения относятся фреймворки ориентированные на данных и фреймворки использующие функциональную декомпозицию. Большинство фреймворков этого уровня являются гибридами и используют оба подхода, но так как возможно использование только одного из них, то эти подходы будут рассмотрены независимо друг от друга.
Читать полностью »

Введение во фреймворки (Часть 1)

2012-08-31 в 9:14, admin, рубрики: automation testing, testing, капитан очевидность, много букв, тестирование

Автоматизированное тестирование
Автоматизированное тестирование (АТ) наиболее эффективно, когда реализовано с помощью фреймворка. Несмотря на то, что в АТ термин фреймворк зачастую используется для описания совокупности объектов, которая формирует инструмент модульного тестированиия, эта статья будет в основном сфокусирована на фреймворках другого рода. Мы обсудим типы фреймворков, которые могут быть определены как совокупность абстрактных понятий, процессов, процедур и сред, с помощью которой автоматические тесты проектируются, создаются и реализуется. Кроме того, это определение фреймворка включает в себя физические объекты, используемые для создания тестов и их реализации, а также для организации логического взаимодействия между компонентами.
Автоматизированное тестирование (и, следовательно, фреймворки) развивалось годами, формируясь и усложняясь с каждой новой фазой эволюции. Эти фазы могут быть описаны в терминах трех поколений, каждое из которых обладает набором недостатков и преимуществ, благодаря которым каждое из них остается актуальным, несмотря на новые разработки. Представленные ниже понятия обычно используются для автоматизации функционального тестирования, но в некоторых случаях их можно применить и для решения задач модульного тестирования.Читать полностью »

BDD наоборот

2012-08-31 в 9:03, admin, рубрики: agile, aspectj, bdd, cucumber, Блог компании Luxoft, тестирование, метки: agile, aspectj, bdd, cucumber, тестирование

Я читал про BDD, и понял одну вещь: BDD это блаблабла блабла бла. Нету у него нормального определения. Вот, например, написано:

BDD совмещает в себе основные техники и практики TDD и идеи DDD для того чтобы предоставить программистам, тестерам, аналитикам и менеджерам общий процесс взаимодействия по ходу разработки ПО.

Все понятно? Мне — ничего. Поэтому я расскажу, что мы делаем и зачем, из того, что может иметь отношение к BDD.
Читать полностью »

Тестирование табличных данных с hamcrest на Java

2012-08-28 в 12:47, admin, рубрики: java, Блог компании Luxoft, таблицы данных, тестирование, метки: java, таблицы данных, тестирование

Тестирование табличных данных с hamcrest на Java По ходу написания функциональных тестов мне частенько приходилось проверять корректность данных в различных таблицах. Таблицы встречались на веб страницах, базах данных или даже excel файлах. В любом случае, необходимо было проверять, что их содержимое соответствует заданному, то есть тому, что создается в тестовом сценарии.

Этот пост про то, как записывать такие проверки с помощью библиотеки hamcrest и зачем это надо.Читать полностью »

Магия TestFlight, или Подробнее о технологиях Configuration Profile и URL Scheme

2012-08-23 в 11:03, admin, рубрики: ios development, testflight, разработка под iOS, тестирование, метки: ios development, testflight, тестирование

На Хабре уже были статьи про TestFlight (вот тут и тут), но в них речь шла главным образом про его использование и интеграцию/автоматизацию в процесс сборки. А мне всегда было интересно, как это работает изнутри:
• Как происходит сбор идентификаторов устройств? (Если вам непонятно, зачем собирать UDID’ы, пройдите по ссылкам выше)
• Как приложение устанавливается по переходу по ссылке?
• Как создается иконка на Home Screen?
• Все это хаки или легальные способы?

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

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

Практика рефакторинга в больших проектах

2012-08-22 в 11:25, admin, рубрики: Программирование, Проектирование и рефакторинг, рефакторинг, тестирование, метки: Программирование, рефакторинг, тестирование

Некоторое время назад я попал в геймдев, где столкнулся с проектами по 2 млн. строк кода, которые пишут десятки программистов. При таких масштабах кодобазы возникают проблемы неведомого мне ранее характера. Об одной и них я хочу вам сейчас рассказать.

Итак, представьте себе следующую ситуацию. Так уж случилось, что вам надо отрефакторить очень большой кусок кода, целую подсистему. Строк, эдак, на 200К. Причем рефакторинг явно выглядит очень крупным, затрагивающим базовые концепции, по которым построена ваша подсистема. Фактически надо переписать всю архитектуру, сохранив бизнес логику. Такое бывает, если, например, вы сделали один проект и у вас впереди новый, и вы хотите в нём исправить все ошибки прошлого. Допустим, по первым прикидкам, на рефакторинг надо месяца 2, не меньше. В процессе рефакторинга всё должно работать, в том числе нельзя мешать другим программистам добавлять новые фичи и чинить баги в подсистеме. Часто такой рефакторинг бывает насколько сложен, что совершенно невозможно замерджить старый код в новый, а также невозможно выкатить результат по частям. Фактически вам надо заменить двигатель самолёта на лету.

Примеры из практики, как моей, так и моих коллег:

Переделать всю работу с базой данных с чистого JDBC на Hibernate.
Переделать архитектуру сервиса с отсылки-приёмки сообщений на удалённый вызов процедур (RPC).
Полностью переписать подсистему трансляции XML файлов в рантайм объекты.

Что делать? С какой стороны подойти к проблеме? Ниже представлен набор советов и практик, которые нам помогают справиться с этой проблемой. Сначала более общие слова, а потом конкретные методики. В общем-то ничего сверхъествественного, но кому-то может помочь.
Читать полностью »

Тестирование — это не поиск ошибок!

2012-08-20 в 14:40, admin, рубрики: тестирование, управление проектами, метки: тестирование

Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?

А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.Читать полностью »

Сбор статистики загрузки веб-страниц

2012-08-16 в 14:18, admin, рубрики: python, selenium, Веб-разработка, загрузка, Клиентская оптимизация, тестирование, метки: python, selenium, загрузка, клиентская оптимизация

Хотел бы поделитья с сообществом полезным инструментом для фронт-разработчиков, в основном. Инструмент достаточно сыроват, нуждается в развитии. Попросту говоря, это банальный ~~говно~~код, который решает поставленную задачу. Для рефакторинга мне не хватает компетенции.

Какую задачу решаем?

Скрипт позвляет собрать статистику по «полной» загрузке страницы на стороне браузера. Это не равняется времени выдачи страницы сервером, очевидно. Под полной загрузкой я подразумеваю загрузку всех ресурсов страницы (картинки, стили, скрипты) и выполнение браузерного события onload. Как все знают, это время можно посмотреть в firebug. Но очевидно, что для адекватной оценки нужно собрать статистику, т.е. открыть страницу и запомнить время ее полной загрузки не один и не два раза. На основе сотни запусков уже можно говорить о среднем времени полной загрузки, и это будет хорошей метрикой, в моем понимании.
Читать полностью »

Полезные метрики для оценки проектов

2012-08-12 в 22:11, admin, рубрики: метрики, тестирование, управление проектами, метки: метрики, управление проектами

В октябре я уже рассказывала о способах оценки тестирования, все страждующие и сочувствующие могут посмотреть запись здесь. А сегодня мне захотелось затронуть тему метрик проекта в целом, причём метрик не «длягалочных», а метрик «пользуприносящих» и «проектыулучшающих». Именно поэтому, вместо сухих формул и перечня метрик, я расскажу 3 истории из опыта о внедрении и использовании строго определённых метрик в строго определённых условиях — и о результатах, которые с их помощью удалось достичь.

Зачем что-либо измерять?

Есть проект. Ваш любимый, родной, которому вы желаете расти и процветать.
Но как вы оцените его процветание, если нет критериев этого самого процветания?
Как вы сможете оперативно среагировать на проблемы до того, как они стали неисправимыми, если не будете использовать «датчик грядущей Ж»?
Как вы поймёте, что именно следует улучшать, если вам неизвестен источник проблем?

Если вкратце, то метрики нужны, чтобы эффективно управлять проектом: диагностировать проблемы, локализовывать их, исправлять и проверять, правда ли выбранные вами способы решения проблемы помогают.

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

А если не приходят, значит метрику можно смело выбросить ;)Читать полностью »

Информация

Комментарии

Рекомендуем