Как я могу ретроспективно создавать модульные тесты для приложения .NET?

Question

Я новичок в модульном тестировании, но начинаю думать, что мне это нужно. У меня есть приложение веб-форм ASP.NET, которое расширяется в непредвиденных направлениях, что означает, что определенные фрагменты кода адаптированы для многократного использования. Мне нужно постараться, чтобы при смене этих единиц я не нарушал их первоначальное предназначение. Так как же мне лучше применить модульные тесты ретроспективно к существующему коду? Практические советы приветствуются. Спасибо

Answer 1

Очень медленно!

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

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

Я купил себе несколько книг по модульному тестированию, которые помогают мне в этом процессе.

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

Answer 2

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

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

Answer 3

Одним из невысказанных преимуществ модульного тестирования является то, как оно подталкивает классовые конструкции к более низкой связи. Если вы попытаетесь добавить UnitTesting в конце, вы должны быть готовы к:

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

В частности, следует обратить внимание на несколько вещей:

• классы, которые вводят новые классы (обычно здесь высокая связь).
• классы, которые полагаются на инфраструктуру, которой не было во время модульного тестирования, такую ​​как HttpRequest и базы данных

EDIT

Википедия объясняет Модульное тестирование :

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

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

Answer 4

Я столкнулся с той же проблемой.

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

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

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

Как все предлагают, сначала напишите тесты, а затем - свой код (TDD). После того, как все тесты пройдены, замените старый связанный код в вашем приложении полностью протестированным кодом.

Answer 5

Буквально только что сделав это, я хотел бы предложить вам добавлять свои юнит-тесты по одному и фиксировать их в том же темпе.