- Зачем нам нужен автоматизированный блок
тестирование? Насколько это эффективно?
Чтобы выделить части программы и показать, что они «правильные». Они являются контрактом, если вы хотите, чтобы код запускался. Имея это под рукой, они могут быстро и часто сообщать вам, правильно ли работает код.
Модульные тесты позволяют программистам легче изменять код, с большей уверенностью и меньшими побочными эффектами. Это способствует / разрешает рефакторинг кода, который без модульных тестов может быть опасным. Учитывая все это, я считаю, что модульное тестирование сделает ваш код лучше.
Я нахожу их эффективными, но признаю, что это часть кривой обучения. Пока вы не станете действительно хорошими в этом (и я все еще новичок в моем уме), вы будете часто пропускать вещи, но я обнаружил, что это все еще намного лучше, чем ручное тестирование, которое я делал слишком долго. Я нашел почти мгновенную выгоду в модульном тестировании. В моем первом проекте с ним я обнаружил, что экономлю большое количество времени, так как мне не нужно было тестировать вручную столько же, и я был приятно удивлен не раз, когда код, над которым я работал, приводил к сбою тестов в другом месте, что Я бы даже не подумал провести повторное тестирование вручную.
- Если я хочу начать делать автоматизированный
модульное тестирование. С чего мне начать
от? (слышал о нунит)
Nunit это хорошо, MbUnit это хорошо. Для начала прочитайте и выполните упражнения в чтениях. Веб-сайты и блоги по модульному тестированию, разработке через тестирование (TDD) и рефакторингу. У Object Mentor есть хорошая серия по TDD. Затем в какой-то момент выберите код, который у вас есть, и попробуйте.
Книги, которые я предлагаю - Разработка на основе тестирования на примере, Разработка на основе тестирования, Практическое руководство, Искусство модульного тестирования, Рефакторинг (Мартин Фаулер), Рефакторинг рабочей книги, Рефакторинг на шаблоны, Чистый код, и я уверен, что есть и другие .
У меня есть рефакторинг книг в списке, потому что я нашел методы для рефакторинга работы руки с модульным тестированием.
- Нужно ли что-нибудь иметь в виду
при разработке моих классов
облегчить автоматизированное модульное тестирование?
Многие из упомянутых мной книг будут обсуждать это. Ответ и да и нет. Часто лучше спроектированный класс с меньшим количеством зависимостей легче тестировать. Это просто хороший дизайн, но он облегчает тестирование. Есть небольшая дискуссия о том, стоит ли менять код, чтобы сделать его более тестируемым. Я склоняюсь к вам следует. На данный момент для меня мой код в прошлом не включал в себя много идей «хорошего дизайна», поэтому для меня начало этого путешествия по TDD повышает мою осведомленность и уровень хорошего дизайна в моем коде, что отчасти связано с желанием сделать TDD.
- Есть ли в C # встроенная поддержка
автоматизированное модульное тестирование?
Если у вас VS 2008 Pro, да, или система Team, но, естественно, я полагаю, что нет.
- Можем ли мы также протестировать графический интерфейс
модульное тестирование или это просто бизнес
логика?
Да, есть несколько инструментов. Ватин это тот, который приходит на ум.
- Слышали про насмешливые рамки.
Они также для модульного тестирования?
Да. Они позволяют моделировать / тестировать очень сложные объекты , которые вы не можете легко выполнить модульным тестированием.
В своем путешествии по пути TDD я нарочно игнорировал насмешки в начале. Для меня я хотел немного лучше понять, зачем они нужны и как их использовать, если бы они жили без него и сам видел, как я кодирую, где я застряну с традиционными методами TDD.
Еще одна книга, которую я нашел очень полезной, хотя мне больно читать, это «Эффективная работа с устаревшим кодом». Это действительно показывает вам, как, казалось бы, невинный код для неподготовленного может сделать жизнь по-настоящему тяжелой.