The Art of Unit Testing / Искусство модульного тестирования: Foreword

Предисловие ко второму изданию

shurshik93 10.04.14 в 16:07

Дело было, кажется, в 2009. Я выступал на норвежской конференции разработчиков в Осло (ах, Осло в июне!). Все действие происходило на огромной спортивной арене. Организаторы разбили зрительские трибуны на секции напротив которых были установлены подмостки, и шторами из плотной черной ткани разделили пространство на восемь отдельных "залов". Помниться, я как раз заканчивал свой доклад который был не то о TDD, не то о SOLID, не то вообще об астрономии или
еще о чем-то, когда внезапно из соседней секции раздался громкий и хриплый голос, поющий под гитару.

vakimov 11.04.14 в 08:28

Шторы висели так, что я смог заглянуть за них и увидеть того парня из соседней секции, который производил весь этот шум. Конечно, им оказался Рой Ошероув.

vakimov 11.04.14 в 08:42

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

vakimov 11.04.14 в 09:59

Это я и сделал - узнал его получше. А на деле, это он сделал значительный вклад в мою новую книгу "The Clean Coder", а также преподавал со мной три дня в классе TDD. Эти впечатления с Роем были весьма позитивными, и я надеюсь их гораздо больше.

novmicha 10.04.14 в 17:01

Полагаю, что ваше знакомство с Роем во время чтения этой книги будет позитивным, так как эта книга - нечто особенное.

SakhipovRR 11.04.14 в 13:45

Вы когда-нибудь читали саги Миченера? Я - нет, но мне рассказывали, что они все начинаются в “атоме”. Книга, которую Вы держите, не является рассказом Джеймса Миченера, но она действительно начинается в атоме — атоме модульного тестирования.

novmicha 10.04.14 в 17:09

Не заблуждайтесь, листая первые страницы. Это не простое введение в модульное тестирование. Это начало пути, и если вы опытны, вы можете бегло посмотреть первые главы. По ходу книги, главы, основываясь друг на друге, погружают вас на новую глубину. Действительно, если прочитать последнюю главу (не зная, что она последняя), я бы подумал, что следующая глава расскажет о мире во всем мире — серьезно, а что бы вы стали делать дальше, если бы решили проблему модульного тестирования в костных организациях с старыми традиционными системами?

novmicha 10.04.14 в 17:40

Эта книга техническая - глубоко техническая. Тут много кода. Это хорошая вещь. Но Рой не ограничивает себя техническим. Время от времени он достает гитару и прерывается на песню, рассказывая анекдоты из своего профессионального прошлого, или философствует о смысле дизайна, или определения интеграции. Он, похоже, любит рассказывать об ошибках, которые он сделал в далеком темном прошлом 2006-го.

novmicha 10.04.14 в 17:59

Да, и не волнуйтесь, что весь код написан на C#. Я имею в виду, разве кто-то может отличить C# и Java? В любом случае – это не важно. C# использован только для примера, в то время как сами концепции могут применяться и к Java, и C, Ruby, Python, Php и любому другому языку программирования (за исключением разве что COBOL).

Bodro 10.04.14 в 17:21

Будь вы новичёк в модульном тестировании и разработке через тестирование или уже опытны в этих вопросах, в любом случае вы найдете что-то полезное для себя. Так что будьте готовы к удовольствию услышать как Рой споет вам песню "Искусство Модульного Тестирования".

novmicha 10.04.14 в 18:09

Рой, пожалуйста, настрой гитару.

Bodro 10.04.14 в 17:22

Роберт Сесил Мартин (Дядя Боб) CLEANCODER.COM

novmicha 10.04.14 в 18:11

Предисловие к первому изданию

elGatoBinario 10.04.14 в 22:57

Когда Рой Ошероув сказал мне что что он работал над книгой о модульном тестировании, я был очень рад услышать это. Тема тестирования приобретала все большее значение в последние несколько лет, но при этом ощущался острый недостаток материалов по модульному тестированию. Посмотрев на свою книжную полку я увидел книги о разработке через тестирование, о тестировании в целом, но там не было ни одного полноценного руководства по модульному тестированию – ни одной книги которая бы раскрывала тему и и вела читателя от первых шагов к общепринятым практикам. Это ошеломляющая правда. Но ведь модульное тестирование это далеко не новая практика. Как же так получилось?

ChiFuka 11.04.14 в 06:58

Наша индустрия очень молодая. Математики заложили основы нашей работы менее 100 лет назад, но "железо" для реализации их мыслей появилось 60 лет назад. Мы только сейчас обнаружили, как начальная разница между и теорией и практикой повлияла на нашу индустрию.

mangregory 11.04.14 в 08:12

В начале машинные циклы был дорогостоящими. Мы запускали программы пакетами. У программистов было выделенное по расписанию время, и они "пробивали" свои программы на перфокартах и шли в машинный зал. Если программа работала неправильно, вы потеряли вашем время, поэтому вы проверяли листинг программы с ручкой, обрабатывая все сценарии выполнения в голове, все граничные случаи. Я сомневаюсь что в то время идея автоматизированного тестирования представлялась возможной. Зачем использовать машины для тестирования, когда ты можешь использовать их для решения проблем. Дефицит привел нас к темной стороне.

mangregory 11.04.14 в 08:46

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

mangregory 11.04.14 в 08:53

Мы прошли от дефицита к избытку и потеряли середину, но сейчас мы ее восстанавливаем. Автоматизированное модульное тестирование объединяет дисциплину проверки кода "на столе" с вновь приобретенной признательностью к компьютеру, как ресурсу разработки. Мы можем писать автоматизированные тесты на языке разработки, чтобы проверять нашу работу, но не единожды, а так часто, как необходимо. Я не думаю, что есть какая-то столь же мощная практика в разработке программного обеспечения.

mangregory 11.04.14 в 11:52

Я написал это в 2009. Я был счастлив увидев книгу Роя в печатном варианте. Это практическое руководство поможет вам начать и послужит справочником для решения ваших тестовых задачах. "Искусство Модульного Тестирования" это не книга о идеальном сценарии. Она научит вас как тестировать код как есть, как получить преимущество при использовании общих библиотек, и, что важно, как написать код, который легко протестировать.

nekalex 11.04.14 в 10:56

"Искусство Модульного Тестирования" - это важный заголовок который был написан годом ранее, но мы не оказались готовы к нему. Сейчас мы готовы. Наслаждайтесь.

nekalex 11.04.14 в 09:56

Майкл Физерс

nekalex 11.04.14 в 09:58

Предисловие

nekalex 11.04.14 в 09:58

Самым провальным проектом, над которым я работал, был проект в котором были модульные тесты.Или я так думал. Я был руководителем группы программистов, разрабатывающих систему выставления счетов и мы проводили полный цикл разработки через тестирование - писали тест, потом писали код, видели что тест провалился, исправляли код, переписывали код и начинали все снова.

nekalex 11.04.14 в 10:10

Первое время все было хорошо. Думали что хорошо, и у нас были тесты которые показывали, что наш код работает. Но со временем, изменились требования. Мы начали оперативно менять наш код, чтобы соответствовать новым требованиям, и когда мы это делали, тесты ломались, и их нужно было исправлять. Код работал, но наши тесты были настолько слабыми что любое изменение кода приводило к поломке теста, хотя код продолжал корректно работать.

nekalex 11.04.14 в 10:16

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

nekalex 11.04.14 в 10:22

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

nekalex 11.04.14 в 10:40

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

nekalex 11.04.14 в 10:43

Благодарности

nekalex 11.04.14 в 10:22

Я выражаю благодарность Майклу Стефансу и Нермине Миллер из Mannig, которые прошли со мной все шаги этого длинного пути, помогли опубликовать эту книгу. Так же спасибо всем в Manning, кто работал над вторым изданием на передовой и за кулисами.

nekalex 11.04.14 в 13:28

Спасибо Джим Ньюкирк, Майкал Физерс, Жерард Меззарос, и многим другим, кто делился со мной идеями, для создания этой книги. И отдельная благодарность Дяде Бобу Мартину, за предисловие ко второму изданию.

nekalex 11.04.14 в 13:31

Дальше список лиц прочитавших рукопись на различных этапах ее развития. Я благодарен им за обратную связь. Aaron Colcord, Alessandro Campeism, Alessandro Gallo, Bill Sorensen, Bruno Sonnino, Camal Cakar, David Madouros, Dr. Frances Buontempo, Dror Helper, Francesco Goggi, Iván Pazmiño, Jason Hales, João Angelo, Kaleb Pederson, Karl Metivier, Martin Skurla, Martyn Fletcher, Paul Stack, Philip Lee, Pradeep Chellappan, Raphael Faria, и Tim Sloan. Так же спасибо Rickard Nilsson, который сделал корректировку рукописи перед публикацией.

nekalex 11.04.14 в 13:34

И напоследок, хочется сказать спасибо всем читателям книги Manning’s Early Access Program за ваши комментарии на форуме. Вы помогли сделать книгу лучше.

nekalex 11.04.14 в 02:35

Об этой книге

mangregory 11.04.14 в 08:55

Одна из самых умных вещей, которую я когда либо слышал от кого-то об обучении (и я забыл кто это был), чтобы научиться чему-то, учи других. Работа над первым изданием книги и публикация в 2009 оказались ничтожно малым учительским опытом для меня. Изначально я писал книгу, потому что устал от одних и тех же вопросов. Но были и другие причины. Я хотел попробовать что-то новое; Я хотел поэкспериментировать; Мне было интересно чему я могу научиться в процессе написания книги, неважно какой. Модульное тестирование было тем, в чем я был хорош. Я так думал. Проклятье в том, что чем более ты опытен, тем глупее себя чувствуешь.

mangregory 11.04.14 в 12:10

В первом издании есть части с которыми сегодня я не согласен - например, что модуль относится к методу. Это не всегда правда. Модуль - это единица работы, что обсуждается в первой части второго издания. Он может быть маленьким, как метод, или большим, как несколько классов (возможно сборок) ... и есть другие изменения, как вы увидите ниже.

mangregory 11.04.14 в 13:41

Изменения во втором издании

ChiFuka 11.04.14 в 06:59

Во втором издании, Я добавил материал о сравнении ограниченной и неограниченной изоляции общих библиотек и новую главу 6 о том, как добиться хорошей изоляции общей библиотеки и как общая библиотека Typemock работает внутри.

nekalex 11.04.14 в 13:14

Я больше не использую RhinoMocks. Держитесь в стороне от неё, она умерла, по крайней мере пока. Я использую NSubstitute для примеров принципов изоляции общей библиотеки. Я так же рекомендую FakeItEasy. Я не схожу с ума по поводу MOQ, по причинам описанных в главе 6.

nekalex 11.04.14 в 13:18

Добавил больше техник в главу о внедрении модульного тестирования на организационном уровне.

ChiFuka 11.04.14 в 06:59

Есть много конструктивных изменений в коде. В большинстве случаев, я перестал использовать свойства и больше использовать внедрение конструктора. Немного рассуждений о принципах SOLID, чтобы подготовить почву для будущего.

nekalex 11.04.14 в 13:23

Разделы, связанные со сборкой части 7 также содержат новую информацию. Я узнал много нового об автоматизации и шаблонах со времени первого издания

mangregory 11.04.14 в 13:44

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

mangregory 11.04.14 в 13:47

В главе 10, инструменты для совместимости, после обновления кода.

nekalex 11.04.14 в 09:51

Поработав с Ruby последние 3 года, дали мне больше перспектив о дизайне и тестировании аргументов, что отражено в 11 главе. Инструменты и библиотеки обновлены новыми инструментами а старые инструменты удалены.

nekalex 11.04.14 в 10:49

Для кого эта книга

nekalex 11.04.14 в 02:36

Эта книга может быть полезна всем кто занимается разработкой программного обеспечения. Все примеры приведены на языке C#, но они так же могут быть полезны другим разработчикам для платформы .NET,а так же разработчикам на других объектно-ориентированных языков программирования со статической типизацией (VB.NET, Java, C++). Если вы архитектор ПО, разработчик, менеджер проекта, специалист тех. поддержки или начинающий разработчик - эта книга будет полезна для вас.

nekalex 11.04.14 в 09:41

Рекомендации к прочтению

SakhipovRR 11.04.14 в 13:47

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

Bodro 10.04.14 в 17:27

В 1-ой части рассматривается написание юнит-тестов "с нуля". Главы 1 и 2 охватывают самые основы, например, использование фреймворков модульного тестирования (NUnit), и содержат описание основных атрибутов ([Test] и [TestCase] и т.п.). В этих главах также объясняются идеи утверждений (asserts), игнорируемых тестов (ignoring tests), тестирования единицы работы (unit-of-work testing). Кроме того, рассматриваются 3 типа результатов модульного теста и три типа тестов. необходимых для них: тестирование значений, тестирование состояния и тестирование взаимодействия.

dima117 11.04.14 в 10:11