Начало работы с автоматизированной интеграцией / модульным тестированием в существующей кодовой базе

Question

Предыстория: Нам передана очень большая кодовая база (1,4 миллиона строк), которая в основном находится на C #.Приложение состоит в основном из asmx web-сервисов в стиле asp.net 2.0, осуществляющих доступ к данным в базе данных SQL Server 2008, а также в различных XML-файлах.Там нет существующих автоматизированных тестов на месте.У нас есть автоматизированная ночная сборка на месте (CC.NET).

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

Как мне пойти изолировать хранилища данных для получения согласованных результатов тестирования?Будут ли какие-либо инструменты тестирования работать лучше для этого подхода, чем другие?XUnit?MS тесты?NUnit?

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

Answer 1

Моя компания делает нечто подобное с нашей базой кода (C, а не C #), которая насчитывает около миллиона строк. Шаги пошли примерно так:

1) Напишите несколько автоматических тестов, подобных описанным вами, которые выполняют тесты системного уровня.
2) Реализуйте правило, согласно которому новый код должен иметь модульный тест.
3) Когда в области есть несколько ошибок, процесс исправления этих ошибок должен включать в себя написание базового модульного теста.

Дело в том, что 3 не должен требовать полного модульного теста (если людям будет легче это делать). Если вы перейдете от 0% покрытия тестом к 40% покрытия конкретного модуля, то вы добились большого прогресса.

Хотя через 6 месяцев у вас может быть до 5% от общей базы кода, но 5% - это код, который больше всего меняется и в котором вы, скорее всего, будете вносить ошибки. Код, над которым я сейчас работаю, примерно на 60% покрыт интеграционными тестами, а 15% (построчно) - модульными тестами. Это не так уж много, но это дает значительную ценность, и наши усилия по разработке выиграли от этого.

edit: В ответ на один из других комментариев текущий набор интеграционных тестов, который мы выполняем, занимает в настоящий момент около 14 часов. Сейчас мы планируем запустить некоторые из них параллельно, чтобы ускорить их.

Answer 2

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

1. Напишите хотя бы один простой тест для каждого API веб-службы, чтобы убедиться, что у вас есть все для охвата
2. Определите API, которые исторически были склонны к сбоям, основываясь на прошлых сообщениях об ошибках. Напишите более подробные тесты для этих API.
3. Каждый раз, когда вы сталкиваетесь с ошибочным тестом, опускайте уровень и пишите тесты для методов, вызываемых по этому пути кода. В конце концов вы обнаружите, что один из этих тестов не проходит. Если ошибка не очевидна на этом уровне, опустите уровень и повторите.
4. Полоскать, стирать, повторять каждый раз, когда вы получаете новый отчет об ошибке.

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

Answer 3

Одна вещь, на которую вы могли бы обратить внимание, это использовать пользовательские истории, используя что-то вроде SpecFlow .Я обнаружил, что эти истории более естественным образом соответствуют интеграционным тестам, что вам и нужно.Дополнительным преимуществом их использования является то, что он создает набор практически сценариев использования, которые могут использоваться группами, не являющимися техническими (например, управляющими продуктами / бизнес-аналитиками).

Answer 4

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

Для изоляции хранилищ данных мне нравится делать следующее:

1. Иметь набор жестко закодированных данных, с которого нужно начинать сначала

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

3. Если что-то пойдет не так в процессе производства из-за набора «неверных данных», добавьте их в свой тест.В конце концов, у вас будет хороший набор тестовых данных, которые тестируют большинство случаев.

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