Как убедиться, что я тестирую все, у меня есть все функции и только те функции для старого кода? - PullRequest
Новая
       8

Как убедиться, что я тестирую все, у меня есть все функции и только те функции для старого кода?

1 голос
/ 17 ноября 2011

У нас довольно большой веб-сайт, у нас есть несколько важных устаревших кодов, которые мы хотим хорошо охватить.

В то же время мы хотели бы получить отчет о функциях, которые мы в настоящее время поддерживаем, ипокрыты.И также мы хотим быть уверены, что мы действительно покрываем каждый возможный угловой случай.Некоторые пути кода являются критическими и потребуют еще много тестов даже после достижения 100% покрытия.

Поскольку мы уже используем rspec, а rspec имеет ключевые слова «feature» и «script», мы попытались создать список, используя rspecвместо того, чтобы идти за огурцом, но я думаю, что этот вопрос может быть применен к любому инструменту тестирования.

Мы хотим что-то вроде этого: 

feature "each advertisement will be shown a specified % of impressions" 
  scenario "As ..."

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

feature "each creative will be shown a specified % of impressions" 
   context "configuration"
     context "display"
      scenario "..."
     context "models"
      it "should ..."
   context "frontend"
    context "display"
      scenario "..."
    context "models"
      it "should ..."

Конфигурация выполняется в другом инструменте, дисплей будет содержать интеграционные тесты, а модели будут содержать модульные тесты.

Я повторяюсь, но идея заключается в том, чтобы убедиться, что функция действительно завершена (включая создание инструмента конфигурации) и протестирована на 100%.

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

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

1 Ответ

0 голосов
/ 17 ноября 2011

Сценарий, который вы описываете, является огромной причиной, почему BDD так популярен.Это вынуждает вас писать код так, чтобы его было легко тестироватьСказав это, вы, очевидно, не собираетесь возвращаться и переписывать все устаревшее приложение.Однако есть несколько вещей, которые вы должны рассмотреть:

  • Проходя по каждому разделу приложения, вы должны спросить себя: «Будет ли сложнее провести рефакторинг, чем писать тесты для этого?».Иногда невозможно избежать рефакторинга перед написанием тестов.
  • Тестирование - это не 100% покрытие, а 100% уверенность.Как вы упомянули, вы планируете писать больше тестов, даже если у вас 100% охват.Это потому что ты идешь на уверенность.Если вы уверены в части кода, двигайтесь дальше.Вы всегда можете вернуться к нему позже.
  • По моему опыту, Cucumber проще для тестов, которые охватывают большую часть приложения.Я думаю, что причина этого в том, что написание тестов на простом английском языке заставляет вас думать о вещах, которых у вас не было бы иначе.Это также позволяет вам сосредоточиться на поведении, а не на коде, и может сделать рефакторинг менее сложной задачей.
  • На самом деле вы не получите много пользы от добавления тестов в существующий код, если никогда больше не трогаете этот код.Начните с тестирования кода, в который вы хотите внести изменения (т.е. рефакторинг) в первую очередь.

Я также рекомендую книгу Предписания по тестированию Rails , в частности одну из последних глав под названием «Тестирование».Унаследованное приложение ".

...