К основному контенту

Сообщения

Сообщения за Март, 2012

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

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

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

"мотивированный конь - это ни разу не ферзь" или IT talk SPb - 3

Ставший уже традиционным отчетик после очередного IT talk-а.
Он будет очень коротким, потому что пересказывать Сашу Орлова бессмысленно :) (в заголовке, кстати, один из его знаменитых перлов)

Его надо слушать, а слушать его в живую вдвойне приятно. Очень много обращений к реальным кейсам, поэтому информация вызывает доверие (если конечно можно не доверять Саше :) Хотя тем, кто следит за его докладами большинство этих кейсов знакомы. Но повторение - мать учения!

Общались на тему решения конфликтов. Саша предлагает использовать алгоритм конструктивной коммуникации.

Такую коммуникацию определяют:

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

Очередное большое спасибо DataArt'у за организацию. Следующая встреча будет посвящена мобильной разработке. Следите за анонсами.

П…

Отзыв по вебинару "С чего начинается автоматизация"

Запись вебинара можно посмотреть на портале об автоматизированном тестировании ПО.

В целом интересно. Понятно, что за час сложно рассказать все по такому вопросу, но обзор по теме сделан хороший.
Основные моменты:

зачем нужна автоматизациякак ее продать (для разных видов разработки: продуктовая, заказная, внутренняя)что нужно знать для успешного ее внедрениякакие инструменты лучше использоватьс чего начатьполезные книгиМиша - молодец :)
Появившиеся у меня вопросы:
Про "что нужно знать и уметь". Миша отметил, что нужно и OOP, и (на выбор) Java, C#, Python (тоже мой любимый :), и администрирование, и Linux и еще кучу всего + навыки тестирования. Это ж где такой комбайн найти :) ?
Может проще поработать с разработчиками и часть их мозгов в этом направлении использовать? Особенно это актуально из-за "кастового" вопроса - сколько раз слышал про то, что разработчик не хочет работать тестировщиком (даже автоматическим). Как вариант - помогать развиваться ручным тестировщик…

Mikado - работаем с legacy code

Обычно изменение, даже самое простое, сделанное в legacy коде, сопровождается массой неприятных вещей: ошибками компилятора, "покрасневшими" приемочными тестами (СЛАВА ВАМ, если они у вас есть!) и тд. Вы исправляете эти места, начинают взрываться новые, и это продолжается бесконечно и кажется неконтролируемым. В какое то момент вам начинает казаться, что проще все сделать заново, чем исправлять существующее. Да-да, обычно так и происходит, чтобы вы не говорили :)

Недавно наткнулся на интересный метод, который предлагает простое решение этой проблемы. Метод называется Mikado. (Обожаю я японские слова, но тут японцы не поучаствовали. Ну, разве что слово у них взяли: термин попал из игры с палочками)



В чем заключается этот способ?

Давайте сначала пару слов о том, что такое  legacy код? Одно из определений гласит, что это код, который написали не вы, но вы сейчас за него ответственны. Michael Feathers в своей книге "Working effectively with legacy code" определяет …

IT Talk SPb - 3-я встреча, анонс

DataArt похоже решил не сбавлять темпа и продолжает развивать тему IT Talk-ов в Питере.
На новую встречу, которая ожидается 29 марта, в качестве спикера приглашен Александр Орлов.

Не пропустите, это будет интересно! Саша очень хороший рассказчик и тема интересная: "Прикладная IT-конфликтология: как не убиться о стену (непонимания), решая конфликт с коллегами".

Идем, смотрим программу и регистрируемся.

Чтобы стать участником IT talk, достаточно прислать контактную информацию: имя, e-mail на адрес:  it-talk.spb@dataart.com  или позвонить по тел.: +7-812-333-4440 /ex 1224, 1225/ +7-921-772-07-65, +7-921-442-44-77

Отчеты с предыдущих "толков" можно найти у меня: IT Talk SPb-1, IT TalkSPb-2.

Краткий курс энтомологии в рамках BDD и TDD

Goblin Game: Еще раз про Automation Bias: TDD, BDD и роющие осы

Сергей Высоцкий написал интересный пост про то, можно ли целиком и полностью доверяться BDD и TDD тестам. Я не согласен с тем, что тест не может в итоге стать постоянно "зеленым". Понятно, что в процессе разработки мы будем иметь его "моргающим". Но после завершения реализации истории, он должен стать "вечно" зеленым. Иначе с этим тестом что-то не так. Другими словами, покраснение теста - это сигнал. Если в сюите есть "моргающие" тесты - это надо лечить.

Обзор VersionOne о состоянии Agile разработки

VersionOne подготовил очередной обзор состояния Agile разработки. В его составлении поучаствовало более 6000 человек.
Здесь только те цифры, которые меня заинтересовали, подробный отчет можно скачать с сайта VerionOne.
Из всех опрошенных 25% работают в компаниях, где трудятся более 500 человек. При этом более 5 лет Agile применяют в компаниях до 20 человек.

18% опрошенных практикуют Agile (лично) более 5 лет, 37% 3-5 лет. Итого 55 % - интересно. А у нас еще обсуждают, что и как... При этом почти в половине компаний процесс разработки был адаптирован к Agile практикам уже больше 2 лет назад.

Интересно, что сам факт применения Agile в компании не означает того, что все проекты работают  по Agile. В 60% компаний только половина и меньше проектов переведены на Agile.

В 77% компаний решение о внедрении Agile принималось руководством.

Какие Agile методологии используются?
























Какие Agile практики используются?














Прикольно: у 16 % Agile проекты всегда успешны.

Причины внедрения Agile
























64% отвечающих …

Тестируем свой код - книги в помощь

Полезные книжки для изучения TDD и unit-тестирования.
Тут только те, что сам читал (примечание: читаю я в основном на английском, не могу ничего сказать насчет русских переводов). Пошерстив чуток интернет, нашел отзывы и мнения и решил ими поделиться.

Классика: "Test Driven Development: By Example" Kent Beck
Отзыв на русское издание: "Экстремальное программирование. Разработка через тестирование",  все по делу написано.

Еще одна отличная книга The Art of Unit Testing Roy Osherove
Во время написания книги Рой работал в команде TypeMock. Он активно проводит тренинги на тему TDD. Сейчас правда перескочил с .Net на Ruby и в основном занят продвижением своей новой книги про лидерство в командах разработки. Но я отвлекся. Вот неплохой отзыв и еще один. Кстати, сам Рой дает свой список книг на тему разработки.

Если мы говорим о рефакторинге уже написанного кода, то тут вам в помощь Working Effectively with Legacy Code от Michael Feathers. Книгой очень удобно пользоваться,…

Белая книжная полка для менеджера

Уже больше года слежу за тем, что делают два очень умных человека: Слава Панкратов и Саша Орлов. Они обладают загадочной способностью: умением зажигать мозг говоря простые и понятные слова. Более того, иногда кажется, что ты это уже знал раньше, но почему то не использовал, не применял. Сейчас они занимаются своим проектом Стратоплан, где можно найти много умного и полезного для себя, если вы руководите разработкой или планируете этим заняться :)

Недавно Саша Орлов решил заняться "мебельным" делом и начал с белой книжной полки. Причем этот интерьер мебели отдается бесплатно в хорошие руки, более того он уже заполнен полезной литературой :)
Полка весьма компактна и помещается всего в 5MB. Найти ее можно здесь.

Вообще, это посты Саши с его блога, объединенные по темам.

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

"О карьере".
Советы о том, как следует строить свою карьеру, карьеру менеджера (хотя большинство советов не только для них).
Из ценного для …

Переключите тумблер или умные люди дурного не посоветуют

Навеяно интересными вопросами про TDD после вчерашнего выступления.

Uncle Bob: "Flipping the Bit"

Подробнее постараюсь перевести чуть позже, пока только это:
Как определить, что у коллеги (или у вас) ТУМБЛЕР переключен?  Если ваши ответы на вопросы ниже совпадают с приведенными - то все хорошо :)
Мантра:

Сможете ли вы выполнить работу быстрее используя TDD? ДАСуществуют ли какие-либо задачи, которые вы можете выполнить быстрее без TDD? НЕТЯ понимаю, что TDD может помочь в долгом проекте, а что если у вас короткая задача? Будете использовать TDD? Да, потому что TDD быстрее даже в короткой перспективеЧто если времени реально не хватает, и босс стоит над душой, будете ли вы использовать TDD? ДАВ любом случае? ДАЕсть ли случаи, когда вам не нужно использовать TDD? НЕТПредставьте себе что вы на звездном корабле Enterprise (Star track) и осталась всего секунда до взрыва антиматерии. Все что вам нужно, чтобы избежать этого, поменять один IF. Будете ли вы использовать TDD? ДАПочему? П…

Можно ли обойтись без тестировщиков? DataArt IT talk SPb - 2

Update: slideshare глючит, podfm со слайдкастом умер, запись в mp3 (качество не айс). Вот мое из свеженького на эту тему, чуть короче и буквами.

Слайды этого доклада можно посмотреть тут.

Состоялась вторая встреча DataArt IT talk SPb. Я там выступал с докладом "Можно ли обойтись без тестировщиков?"
Как получилось судить не мне, надеюсь, что участникам было интересно. Аудитория была процентов на 90 - как раз тестировщики :), говорить им о том, что они возможно не нужны было "забавно".

PS Это выступление было первым, надо еще тренироваться :) Мое "а-а-а-а-а" и "э-э-э-э" напрягает :( Ну и вопросы надо повторять, тороплюсь ответить.