Автоматическое тестирование модулей - почему? что? который?

Ответ 1

Зачем нам нужно автоматическое модульное тестирование? Насколько это эффективно?

Автоматическое модульное тестирование очень ценно прежде всего потому, что оно автоматизировано (обычно мы рассматриваем его как "unit test", когда оно автоматическое). По мере роста размера приложения вручную тестирование всего приложения может занимать часы или даже недели. Даже тестирование только небольшой части приложения требует времени и подвержено ошибкам. Если вы не аутисты, вы не сможете сосредоточиться на выполнении каждого ручного теста на 100% правильно, если вам приходится делать это много раз.

В Agile-разработке мы работаем с концепцией Rapid Feedback: чем скорее вы сможете получить обратную связь о том, что вы сделали, но и правильно или неправильно, тем эффективнее вы можете быть. Мы все совершаем ошибки, но гораздо дешевле обнаружить и исправить ошибку через тридцать секунд после ее создания, чем несколько дней или недель спустя. Вот почему автоматическое тестирование так важно.

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

Если я хочу начать автоматическое модульное тестирование. С чего начать? (слышали о nunit)

Прежде всего, вам нужно изучить некоторые основы тестирования модулей. Книга Роя Ошерове Искусство модульного тестирования - хорошее введение.

Когда дело доходит до фреймворков, NUnit существует уже давно, но у него есть некоторые неотъемлемые проблемы.

Если у вас уже есть Visual Studio Professional или Team System, есть встроенная модульная система тестирования, известная как MSTest. Большинство людей не любят эту структуру, но лично я считаю ее вполне адекватной. Интеграция IDE работает хорошо, но API может быть лучше.

Если вы ищете бесплатную инфраструктуру тестирования модулей с открытым исходным кодом, я бы порекомендовал xUnit.net, который является гораздо более современным рамки.

Должен ли я иметь в виду что-то при разработке моих классов, чтобы облегчить автоматическое тестирование модулей?

Да, каждый класс должен быть использован изолированно. Это может быть очень сложно сделать по предварительному дизайну, или если вы пытаетесь модифицировать модульные тесты на существующий код, но должны быть более или менее естественными, если вы примете Test-Driven Development (TDD).

Поддерживает ли С# встроенную поддержку автоматизированных модульных испытаний?

Нет, С# - это всего лишь язык, но, как я уже упоминал выше, некоторые версии Visual Studio имеют MSTest.

Можем ли мы также протестировать GUI с автоматическим модульным тестированием или это просто бизнес-логика?

Единичный анализ GUI имеет тенденцию быть очень хрупким (т.е. проверка обслуживания очень высока), поэтому, как правило, это не очень хорошая идея.

Однако существует много шаблонов проектирования, которые могут помочь вам извлечь всю логику GUI в тестируемые классы: Modev-View-Controller, Model-View-Presenter, Application Controller, Model-View-ViewModel и т.д.

Вы можете выполнять автоматические тесты всего приложения через такие интерфейсы, минуя только часть рендеринга GUI. Такие тесты называются подкожными испытаниями, но считаются интеграционными испытаниями, а не модульными тестами.

Выслушали насчет насмешливых фреймворков. Являются ли они также для модульного тестирования?

Динамические макетные библиотеки предназначены только для модульного тестирования.

Некоторые хорошие и популярные -

• Moq
• Rhino Mocks

Ответ 2

• Зачем нам нужен автоматизированный блок тестирование? Насколько это эффективно?

Чтобы изолировать части программы и показать, что они "правильные". Они являются контрактом, если вы хотите, как код должен работать. Благодаря этому они могут быстро и часто говорить вам, если код работает правильно.

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

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

• Если я хочу начать автоматизировать модульное тестирование. С чего начать? из? (слышали о nunit)

Нунит хорош, MbUnit хорош. Чтобы начать, читайте и делайте упражнения в показаниях. Веб-сайты и блоги по модульному тестированию, тестированию (TDD) и рефакторингу. У объекта Mentor есть хорошая серия для TDD. Затем в какой-то момент выберите код, который у вас есть, и попробуйте его.

Книги, которые я предлагаю, - Test Driven Development, например, Test Driven Development, Практическое руководство, Искусство модульного тестирования, Рефакторинг (Martin Fowler), Рефакторинговая книга, Рефакторинг для шаблонов, Чистый код, и я уверен, что есть другие.

У меня есть рефакторинг книг в списке, потому что я нашел методы работы с рефакторингом вручную с модульным тестированием.

• Нужно ли мне что-либо помнить при проектировании моих классов облегчить автоматическое тестирование модулей?

Многие из упомянутых мной книг обсудят это. Ответ и да и нет. Часто более эффективный класс, который имеет меньше зависимостей, легче тестировать. Это просто хороший дизайн, но это облегчает тестирование. Есть немного дебатов, если вы должны изменить код, чтобы сделать его более проверяемым. Я наклоняюсь к тебе. На данный момент для меня мой код в прошлом не включал в себя много идей "хорошего дизайна", поэтому для меня, приступая к этому путешествию TDD, я увеличил свою осведомленность и уровень хорошего дизайна в своем коде, что отчасти желало сделать TDD.

• Имеет ли С# встроенную поддержку для автоматическое тестирование модулей?

Если у вас есть VS 2008 Pro, да или Team, но, естественно, я полагаю, что вы этого не делаете.

• Можем ли мы также протестировать графический интерфейс с автоматическим модульное тестирование или это просто бизнес логика?

Да, есть несколько инструментов. Ватин - это тот, который приходит на ум.

• Вы слышали о насмешливых фреймворках. Являются ли они также для модульного тестирования?

Да. Они позволяют имитировать/тестировать очень сложные объекты, что вы не можете легко unit test.

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

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

Ответ 3

Пункт 1) Он дает вам постоянный обзор того, что работает, а что нет. Как только вы измените простую функцию, вы получите результат, если это изменение приведет к повреждению. Кроме того, вы можете позже реорганизовать все свое приложение, и пока ваш unit test будет зеленым, все будет хорошо. Просто этот момент очень важен. Или вы когда-либо делали проект, который никогда не нужно реорганизовывать?

Точка 2) NUnit - хорошее место для начала, но есть несколько других фреймворков unit test. Также я предлагаю взглянуть на CruiseControl или другие инструменты непрерывной интеграции, которые отнимают много работы от разработчика.

Пункт 3). Ну, наверняка люди, которые могут сказать вам часы и часы, что делать, а что нет. Поскольку мой фон unit test ограничен, чтобы использовать его для встроенных устройств, мы имеем совсем другие результаты.

Точка 4). С# - это язык программирования, а не тестовая структура..Net имеет по крайней мере один атрибут, который может помочь во время модульных тестов, то есть InternalsVisibleTo-Attribute, чтобы ваши внутренние классы и методы были общедоступны для одного определенного типа.

Точка 5) Если у вас хорошо спроектированное приложение, вам не нужно проверять ваш gui. Подумайте об этом: у вашего gui нет кода. Каждая кнопка, которую пользователь может нажать, отображается на контроллер. Каждый вход, который пользователь может предоставить, передается контроллеру. Итак, что вы должны испытать в своем gui? Все, что вам нужно сделать, это проверить работоспособность вашего контроллера. И с этой MVVM/MVC/WhatElseArchitecture у вас есть одна с одной стороны хорошо спроектированное приложение, а с другой - приложение, которое просто проверить.

Ответ 4

• Зачем нам нужен автоматизированный блок тестирование? Насколько это эффективно?

Очень.

• Если я хочу начать автоматизировать модульное тестирование. С чего начать? из? (слышали о nunit) Начните с nunit - его очень легко

• Нужно ли мне что-либо помнить при проектировании моих классов облегчить автоматическое модульное тестирование? Если вы добьетесь успеха в unit test, тогда вы захотите.

• Поддерживает ли С# встроенную поддержку автоматизированное модульное тестирование? Нет - но Visual studio делает - но я не рекомендую использовать его

• Можем ли мы также протестировать графический интерфейс с автоматическим модульное тестирование или это просто бизнес логика? Все может быть автоматизировано, просто вопрос о том, как трудно это сделать.

• Узнали о насмешливых фреймворках. Являются ли они также для модульного тестирования? Да.

Прочитано Roy Osherove Искусство модульного тестирования.

Ответ 5

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

Автоматизируя тесты, вы делаете их удобными для запуска, поэтому они будут запущены.

Ответ 6

Why do we need to have automated unit testing? How effective is it?

• Нет. Вам решать, хотите ли вы этого или нет. Это будет только так эффективно, как вы это делаете. Вы должны пойти на автоматизацию только в том случае, если вы собираетесь повторять цикл тестирования для кода более 3 раз!!! Если я хочу начать автоматическое модульное тестирование. С чего начать? (слышали о nunit)

• Независимо от того, что вам удобно, сделайте его своей отправной точкой, а затем изучите его и используйте в своих интересах. Можем ли мы также протестировать GUI с автоматизированным модульным тестированием или это просто бизнес-логика?

• Вы можете, но не должны. GUI лучше проверять вручную. Глаза будут ломать больше ошибок в интерфейсе, чем машина. Выслушали насчет насмешливых фреймворков. Являются ли они также для модульного тестирования?

• Да, большинство модулей, таких как TestNG, Junit и т.д., предназначены для тестирования модулей.