Автоматизированное модульное тестирование - почему? что? который?
Это означает, что вы внесли некоторые несовместимые двоичные изменения в библиотеку без перекомпиляции кода клиента. Спецификация языка Java §13 описывает все такие изменения, наиболее заметно, изменение нефайловых полей / методов не static как static или наоборот.
Перекомпилировать клиентский код против новой библиотеки, и вам должно быть хорошо идти.
UPDATE: если вы публикуете публичную библиотеку, вы должны избегать несовместимых двоичных изменений в максимально возможной степени, чтобы сохранить так называемое «двоичное обратное» совместимость". Обновление баннеров зависимостей в идеале не должно нарушать приложение или сборку. Если вам нужно нарушить двоичную обратную совместимость, рекомендуется увеличить основной номер версии (например, от 1.x.y до 2.0.0), прежде чем отпускать изменение.
5 ответов
Зачем нам нужно автоматическое модульное тестирование? Насколько оно эффективно?
Автоматическое модульное тестирование очень ценно прежде всего потому, что оно автоматизировано (обычно мы рассматриваем его как «модульное тестирование» только тогда, когда оно является автоматизируемым). По мере роста размера приложения ручное тестирование всего приложения может занять часы или даже недели. Даже тестирование небольшой части приложения требует времени и подвержено ошибкам. Если вы не страдаете аутизмом, вы не сможете сосредоточиться на выполнении каждого ручного теста на 100% правильно, если вам придется делать это снова и снова десятки раз.
В Agile-разработке мы работаем с концепцией быстрой обратной связи: чем раньше вы получите отзыв о том, что вы сделали правильно или неправильно, тем эффективнее вы сможете действовать. Мы все ошибаемся, но гораздо дешевле обнаружить и исправить ошибку через тридцать секунд после ее совершения, чем через несколько дней или недель. Вот почему автоматическое тестирование так важно.
Хотя автоматическое тестирование можно проводить на многих уровнях, модульное тестирование является наиболее эффективным типом для реализации. Это может быть самая сложная дисциплина тестирования для понимания и освоения, но она намного надежнее, чем любой другой тип тестирования.
Если я хочу начать автоматическое модульное тестирование. С чего мне начать? (слышали о nunit)
Прежде всего, вам нужно изучить основы модульного тестирования. Книга Роя Ошерова Искусство модульного тестирования - хорошее введение.
Когда дело доходит до фреймворков, NUnit существует уже давно, но у него есть некоторые внутренние проблемы.
Если вы это уже сделали. иметь Visual Studio Professional или Team System, есть встроенная среда модульного тестирования, известная как MSTest. Большинству людей этот фреймворк не нравится, но лично я считаю его вполне адекватным. Интеграция IDE работает хорошо, но API мог бы быть лучше.
Если вы ищете бесплатную среду модульного тестирования с открытым исходным кодом, я бы порекомендовал xUnit.net , которая является гораздо более современной средой. .
Нужно ли мне помнить что-нибудь при проектировании моих классов, чтобы облегчить автоматическое модульное тестирование?
Да, каждый класс должен иметь возможность использоваться изолированно. Это может быть очень сложно сделать предварительным проектированием или если вы пытаетесь модернизировать модульные тесты для существующего кода, но это должно происходить более или менее естественно, если вы применяете разработку через тестирование (TDD).
Есть ли в C # встроенная поддержка автоматического модульного тестирования?
Нет, C # - это просто язык, но, как я уже упоминал выше, в некоторых версиях Visual Studio есть MSTest.
Можем ли мы также тестировать графический интерфейс с помощью автоматизированного модульного тестирования или это просто бизнес-логика?
Графический интерфейс модульного тестирования имеет тенденцию быть очень хрупким (то есть, поддержка тестирования очень высока), поэтому как правило, не очень хорошая идея.
Однако существует множество шаблонов проектирования, которые могут помочь вам извлечь всю логику графического интерфейса в тестируемые классы: Modev-View-Controller, Model-View-Presenter, Application Controller, Model-View-ViewModel, и т. д.
Вы можете выполнять автоматические тесты всего приложения через такие интерфейсы, минуя только часть визуализации графического интерфейса. Такие тесты называются подкожными тестами, но считаются интеграционными, а не юнит-тестами.
Слышали о макетных фреймворках. Они также предназначены для модульного тестирования?
Динамические фиктивные библиотеки только предназначены для модульного тестирования.
Некоторые хорошие и популярные:
Пункт 1) Он дает вам непрерывный обзор того, что работает, а что нет. Как только вы измените простую функцию, вы получите результат, если это изменение что-то сломает. Кроме того, позже вы можете провести рефакторинг всего приложения, и, поскольку все ваши модульные тесты становятся зелеными, все работает нормально. Как раз этот момент очень важен. Или вы когда-нибудь делали проект, который никогда не подвергался рефакторингу?
Пункт 2) NUnit - хорошее место для начала, но есть несколько других сред модульного тестирования. Также я предлагаю взглянуть на CruiseControl или другие инструменты непрерывной интеграции, которые берут на себя много работы от разработчика.
Пункт 3) Ну, наверняка есть люди, которые могут часами рассказывать вам, что делать, а что нет. Поскольку мой опыт работы с модульными тестами ограничен его использованием для встраиваемых устройств, у нас есть совсем другие трудности.
Пункт 4) C # - это язык программирования, а не среда тестирования. .Net имеет по крайней мере один атрибут, который может помочь во время модульных тестов, это InternalsVisibleTo-Attribute, чтобы сделать ваши внутренние классы и методы общедоступными для одного конкретного типа.
Пункт 5) Если у вас есть хорошо разработанное приложение, вам не нужно проверьте свой графический интерфейс. Подумайте об этом: в вашем графическом интерфейсе нет кода. Каждая кнопка, которую может нажать пользователь, привязана к контроллеру. Каждый ввод, который может предоставить пользователь, передается контроллеру. Итак, что вам нужно протестировать в своем графическом интерфейсе? Все, что вам нужно сделать, это протестировать ваш контроллер и проверить его работоспособность.
- Зачем нам нужна автоматизированная установка тестирование? Насколько это эффективно?
Чтобы изолировать части программы и показать, что они «правильные». Если вы хотите, это договор о том, как должен запускаться код. Имея это под рукой, они могут быстро и часто сообщать вам, работает ли код правильно.
Модульные тесты позволяют программистам более легко изменять код, с большей уверенностью и меньшими побочными эффектами. Он способствует / разрешает рефакторинг кода, который без модульных тестов может быть опасен. Имея все это в виду, я считаю, что модульное тестирование улучшит ваш код.
Я считаю их эффективными, но признаю, что это часть кривой обучения. Пока вы не станете действительно хороши в этом (а я все еще новичок в своем уме), вы часто будете что-то упускать, но я обнаружил, что это все же лучше, чем ручное тестирование, которое я проводил слишком долго. Я обнаружил почти мгновенную выгоду в модульном тестировании. В моем первом проекте с ним я обнаружил, что я экономлю большое количество времени, поскольку мне не нужно было вручную тестировать почти столько же, и я действительно не раз был приятно удивлен, когда код, над которым я работал, приводил к сбою тестов в другом месте, что Я бы даже не подумал провести повторное тестирование вручную.
- Если я хочу начать автоматизировать модульное тестирование. С чего мне начать от? (слышал о nunit)
Nunit - это хорошо, MbUnit - хорошо. Для начала прочтите и выполните упражнения в чтениях. Веб-сайты и блоги, посвященные модульному тестированию, разработке через тестирование (TDD) и рефакторингу. У Object Mentor есть хорошая серия статей о TDD. Затем в какой-то момент выберите какой-нибудь код, который у вас есть, и попробуйте его.
Книги, которые я предлагаю - Разработка через тестирование на примере, Разработка через тестирование, Практическое руководство, Искусство модульного тестирования, Рефакторинг (Мартин Фаулер), Рабочая тетрадь по рефакторингу, Рефакторинг к шаблонам, Чистый код и я уверен, что есть и другие.
У меня есть книги по рефакторингу в списке, потому что я обнаружил, что методы рефакторинга работают рука об руку с модульным тестированием.
- Нужно ли мне что-то хранить разум при разработке моих классов на облегчить автоматическое модульное тестирование?
Многие из упомянутых мною книг обсуждают это. Ответ и да и нет. Часто лучше протестировать класс с меньшим количеством зависимостей. Это просто хороший дизайн, но он упрощает тестирование. Существует небольшая дискуссия о том, следует ли вам изменять код, чтобы сделать его более тестируемым. Я наклоняюсь к тебе следует. На данный момент для меня мой код в прошлом не включал в себя много идей "хорошего дизайна", поэтому для меня начало этого пути TDD повышает мою осведомленность и уровень хорошего дизайна в моем коде, что отчасти связано с желанием сделать TDD.
- Есть ли в C # встроенная поддержка автоматическое модульное тестирование?
Если у вас есть VS 2008 Pro, да, или система Team, но, естественно, я предполагаю, что у вас нет.
- Можем ли мы также протестировать графический интерфейс с помощью автоматизированных модульное тестирование или это просто бизнес логика?
Да, есть несколько инструментов. На ум приходит Ватин.
- Слышал о насмешливых фреймворках. Они тоже для модульного тестирования?
Да. Они позволяют моделировать / тестировать очень сложные объекты , которые нелегко протестировать.
В моем путешествии по пути TDD я намеренно игнорировал насмешки в начале. Что касается меня, я хотел немного лучше понять, зачем они нужны и как они будут использоваться, живя без них, и лично убедиться, как я кодировал, где я застряну с традиционными методами TDD.
Другой Книга, которую я нашел очень полезной, хотя читать мне больно, это «Эффективная работа с устаревшим кодом». Это действительно показывает вам, как, казалось бы, невинный код для неподготовленного человека может серьезно осложнить жизнь в будущем.
- Зачем нужна автоматизированная установка тестирование? Насколько это эффективно?
Очень.
Если я хочу начать автоматизировать модульное тестирование. С чего мне начать от? (слышали о nunit) Начни с nunit - это очень просто
Нужно ли мне что-то помнить при разработке моих классов на облегчить автоматическое модульное тестирование? Если вы хорошо разбираетесь в модульном тестировании, вы захотите это сделать.
Есть ли в C # встроенная поддержка для автоматическое модульное тестирование? Нет - но Visual Studio умеет - но я не рекомендую его использовать
Можем ли мы также протестировать графический интерфейс с помощью автоматизированного модульное тестирование или это просто бизнес логика? Все можно автоматизировать, вопрос лишь в том, насколько это сложно.
Слышал о макетах фреймворков. Они тоже для модульного тестирования? Да.
Прочтите книгу Роя Ошерова «Искусство модульного тестирования».
Почему автоматическое модульное тестирование просто: потому что по мере роста вашего кода выполнение будет все больше и больше ручное тестирование, что означает, что у вас все меньше и меньше шансов сделать это.
Автоматизируя тесты, вы делаете их удобными для запуска, поэтому они будут выполняться.