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

Сообщения

Сообщения за Март, 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 &quo

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

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

Полезные книжки для изучения 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. Будете ли вы и

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

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