.jpg "Введение во фреймворки (Часть 1)")
Автоматизированное тестирование (АТ) наиболее эффективно, когда реализовано с помощью фреймворка. Несмотря на то, что в АТ термин фреймворк зачастую используется для описания совокупности объектов, которая формирует инструмент модульного тестированиия, эта статья будет в основном сфокусирована на фреймворках другого рода. Мы обсудим типы фреймворков, которые могут быть определены как совокупность абстрактных понятий, процессов, процедур и сред, с помощью которой автоматические тесты проектируются, создаются и реализуется. Кроме того, это определение фреймворка включает в себя физические объекты, используемые для создания тестов и их реализации, а также для организации логического взаимодействия между компонентами.
Автоматизированное тестирование (и, следовательно, фреймворки) развивалось годами, формируясь и усложняясь с каждой новой фазой эволюции. Эти фазы могут быть описаны в терминах трех поколений, каждое из которых обладает набором недостатков и преимуществ, благодаря которым каждое из них остается актуальным, несмотря на новые разработки. Представленные ниже понятия обычно используются для автоматизации функционального тестирования, но в некоторых случаях их можно применить и для решения задач модульного тестирования.Читать полностью »
Рубрика «testing» - 16
Введение во фреймворки (Часть 1)
2012-08-31 в 9:14, admin, рубрики: automation testing, testing, капитан очевидность, много букв, тестированиеКастомная обработка jUnit тестов в TeamCity
2012-08-05 в 10:12, admin, рубрики: junit, teamcity, test automation, testing, тестирование, метки: junit, teamcity, test automation, testing TeamCity поддерживает jUnit «на лету» и особых проблем с выполнением тестов нет. Но стандартная поддержка не покрывает все юзкейсы. Например, никогда нельзя быть уверенным, в какой очередности пройдут тесты. Кроме того, есть другие вариации тестовой архитектуры, которые просто невозможно сделать дефолтными средствами jUnit. Например, определение в рантайме, какие тесты нужно запускать, а какие нет. Причем с выводом в отчетах в TeamCity без проигнорированных тестов.
Читать полностью »
Inline-тесты для PHP
2012-05-20 в 20:09, admin, рубрики: php, phpunit, testing, метки: PHP, phpunit, testing 
Inline-тесты — это тесты, встроенные непосредственно в DOC-комментарии тестируемого скрипта. Такая фишка, насколько я знаю, есть в Python, хотя внятного описания найти не смог. В любом случае, идея мне понравилась, так как inline-тесты имеют ряд преимуществ по сравнению с обычными, которые я изложу ниже. Поэтому хочу предложить Вашему вниманию инструмент для запуска таких тестов для PHP.
Читать полностью »
Пишем тесты здесь и сейчас, иначе возникает большая вероятность откладывания на лучшие времена
2012-04-16 в 11:51, admin, рубрики: ruby, testing, Веб-разработка, тестирование, метки: ruby, testing, тест А чтобы тестировать не отходя от кассы нужен фреймворк который внедряется в код
но никак не влияет на его работу.
Именно это делает Spine — позволяет писать тесты рядом с кодом никак не влияя на работу приложения.
Почему Spine?
Потому что «Specs Inline» и потому что(imho) для рационального ПО, тесты играют роль позвоночника.
Многим это статья может показаться повтором и они будут отчасти правы,
так как данная статья основана на пятой части знакомства с Presto.
А сам Spine вырос из и стал на замену PrestoTest фреймворка.
И зачем повторять то что уже написано?
Просто Spine существенно отличается от PrestoTest и соответственно данная статья тоже отличается от предыдущей, процентов на 80.
Да и представлять новый гем в пятой части знакомства с Presto как-то не корректно.
И да, статья не претендует на большие плюсы. Если вам данная методология не по вкусу,
минусовать не зачем, просто игнорируйте её и используете ваш любимый тест-фреймворк. Спасибо.
Мотивация:
- Визуальный контакт. Я хочу писать спецификации одновременно с кодом
и чтобы они физически находились рядом, в том же файле или папке, но никак не в амбаре. - Простые вещи должны остаться простыми.
foo.should == barникак не заменитfoo == bar - Я не хочу ни запоминать список синтетических заменителей простых вещей
ни работать с документацией под рукой. - Никаких хаков. Тестируемые объекты и базовые классы Ruby должны остаться в
первоначальном состоянии.
Тестирование компонентов и приложений ExtJS/Sencha с использованием движка PhantomJS
2012-03-31 в 22:25, admin, рубрики: extjs, javascript, phantomjs, sencha, testing, webkit, Библиотека ExtJS/Sencha, тестирование, метки: extjs, javascript, phantomjs, sencha, testing, webkit, тестированиеPhantomJS — это сборка движка WebKit без графического интерфейса, позволяющая в режиме консоли загружать веб-страницу, выполнять JavaScript, полноценно работать с DOM, Canvas и SVG. Одним из главных заявленных применений PhantomJS является автоматизированное функциональное тестирование пользовательского интерфейса. PhantomJS имеет интеграцию с различными фреймворками для тестирования JavaScript и веб-страниц. Посмотрим, что можно сделать на базе стандартного функционала PhantomJS, чтобы протестировать отдельный компонент и целое приложение, написанное на ExtJS/Sencha. В этой статье я приведу некоторую простейшую заготовку для тестировочного фреймворка, иллюстрирующую подход к тестированию кода, основанного на сторонней JavaScript-библиотеке. Весь код, представленный в статье, доступен на GitHub.
Интеграция DBUnit и Spring TestContext Framework
2012-03-25 в 14:21, admin, рубрики: database, dbunit, java, junit, spring, testing, тестирование, метки: database, dbunit, junit, spring, testing, тестирование С появлением в Spring 2.5 фреймворка TestContext интеграционное тестирование кода, работающего с базой данных, существенно упростилось. Появились аннотации для декларативного указания контекста, в котором должен выполняться тест, аннотации для управления транзакциями в рамках теста, а также базовые классы тестов для JUnit и TestNG. В этой статье я опишу вариант интеграции фреймворка TestContext с DBUnit, позволяющим инициализировать базу данных и сверить её состояние с ожидаемым по окончании выполнения теста.
Читать полностью »
Блог компании Microsoft / Приглашаем на конференцию Quality Assurance Day
2012-02-10 в 11:46, admin, рубрики: quality assurance, testing, метки: quality assurance, testing
Качество – один из главнейших факторов успеха любого программного обеспечения. Влиять на качество можно разными способами. Это и процессы организации разработки, и методики обеспечения качества кода, архитектурные решения, подходы в области тестирования. Индустрия накопила немало опыта в этой области, и использование этих наработок может помочь решить многие вопросы. Вот почему 30 марта компания Microsoft совместно с CareerLab вот уже в третий раз проводит конференцию Quality Assurance Day – конференцию для тех, кому небезразлично качество ПО.
На этот раз команда организаторов значительно расширила содержательную часть конференции.Читать полностью »
Linux для всех / [archlinux] До нас добрались бинарные логи!
2012-02-09 в 16:04, admin, рубрики: archlinux, testing, метки: archlinux, news, testing![Linux для всех / [archlinux] До нас добрались бинарные логи!](https://www.pvsm.ru/images/d20b71c153f5115be30a97805017c6eb.jpg "Linux для всех / [archlinux] До нас добрались бинарные логи!")
Надеюсь, вам уже страшно жить, потому что иначе Дейв к вам придет.
Нет, не верно, Дейв всё равно к вам придет. А еще Леннарт и много других добрых людей.(предупреждение: текст нарочно написан в пессимистично-ироничном стиле, на память о печальной известности последнего достижения Леннарта. Если вы по натуре не можете выдерживать такой стиль, вам лучше убрать невинных кошек и беременных мужчин от монитора, и дальше не читать.)
Продолжаем эмергенцию в альтернативную реальность, и на этот раз это НЕ testing. Точнее, не совсем.
Леннарт кодит упорно и настойчиво, и вот начиная релиза systemd 38 в нем уже реализован Тот СамыйЧитать полностью »
JAVA / Тестирование в Java. Spock Framework
2012-02-05 в 20:52, admin, рубрики: bdd, groovy, java, spock, tdd, testing, метки: bdd, groovy, java, spock, tdd, testing
В предыдущих статьях на примерах JUnit и TestNG я упоминал о test-driven development(TDD) и data-driven testing(DDT). Но есть еще один активно набирающий популярность подход, behaviour-driven development(BDD). Это такое развитие TDD техники, при котором на тест смотрят не как на тестирование каких-то компонентов системы, а как на требования к функционалу. Если TDD оперирует такими понятиями, как тест или метод, то для BDD это спецификация и требования. Про эту технику уже говорили на хабре ранее:
Эволюция юнит-теста,
Экстремальное программирование, знакомство с Behavior Driven Development и RSpec
Этот подход применим используя и JUnit, иЧитать полностью »