Один день из жизни разработчика ALM: написание нового кода для пользовательского описания функциональности

Вы новый пользователь управления жизненным циклом приложений Visual Studio ALM и Team Foundation Server (Team Foundation Server)?Вы интересуете и команда может получить максимально могут использовать последнюю версию этих средств для построения приложения?

После этого требуется несколько минут в прогулке пошаговое описание этот учебник 2 - главы, а за день в жизнях чен, 2 и Джулии разработчиков на Волокон - вымышленной компании Fabrikam, которая предоставляет кабельное телевидение и связанные службы.Вы увидите примеры использования Visual Studio и Team Foundation Server для извлечения и обновления кода, приостановка работы при запросе будут прерваны, анализ кода, вернете изменения, а также выполнять другие задачи.

Описание функциональности до тех пор

Команда недавно начала занимать Visual Studio и Team Foundation Server для управления жизненным циклом приложений (ALM).Они настроены их сервер и клиентские машины, создали объем невыполненной работы, запланированной итерации и завершенная другое планирование является обязательным, что они начали разработки приложения.

Общие сведения об этой главы

Питер краткое учитывает его и выбирает список невыполненных работ по задаче будет работать на сегодня.Он записывает модульные тесты для кода он планирует разработки.Как правило, он выполняет тесты несколько раз в час, постепенно при создании более детализации тесты, а затем при написании кода, который делает их передачи.Зачастую описывает интерфейс его кода с коллегами, которые будут использовать метод он записывает.

Примечание
Мои функции работы и покрытии кода, которые описаны в этом разделе, доступны только в Visual Studio Premium и Visual Studio Ultimate.

Содержание раздела

• Просмотрите личную списка невыполненных работ по задачам инициировать работы и подготовка

• Создайте первый модульного теста

• Создание заглушки для нового кода

• Выполните первый тест

• Согласитесь API

• Красный, зеленый, рефакторинг…

• Покрытие кода

• При внесении?

• Повторить изменения

Просмотрите личную списка невыполненных работ по задачам инициировать работы и подготовка

В Командный обозреватель, Питер открывает страницу Моя работа.Согласованные командой, что во время текущего спринта, Питер будет работать в состоянии счета Evaluate элемент главного приоритета в невыполненную работу продукта.Питер решит запускать с функциями math ", задачей дочернего элемента невыполненной работы главного приоритета.Он перетаскивает эта задача из списка Доступные рабочие элементы в список *** Рабочие элементы и изменения хода выполнения ***.

Просмотреть список невыполненных работ по личную и подготовить задачи разработки рабочего процесса

1. В командном обозревателе выполните следующее.

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

   2. Выберите Главная, а затем выберите Моя работа.

2. На странице Моя работа перетащите задачи из списка Доступные рабочие элементы к шагу *** рабочие элементы выполняется ***.

   Также можно выбрать задачу в списке Доступные рабочие элементы а затем выбрать Запуск.

План работы черновика пошаговый

Питер обычно начинается код в последовательности мелких шагов.Каждый шаг обычно занимает больше не меньше час и может принимать в качестве немногую как 10 минут.В каждом шаге, он записывает новый модульный тест и изменяет код, он начинает таким образом, чтобы он передает новый тест, в дополнение к тестам он уже записал.Иногда он записывает новый тест перед изменением кода, а иногда он изменяет код перед записью тест.Иногда он выполняется рефакторинг.Иными словами, он просто улучшает код, не добавляя новые тесты.Он никогда не изменяет тест, который передает, если он не будет неправильно представляют определение, что требование.

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

Однако он не проверяет код в Team Foundation Server до тех пор, пока он не будет завершен всей задачи.

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

1. Создайте метод теста stub-, что только подпись метода.

2. Один вариант обычного содержимого конкретного.

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

4. Исключение при недостатке.Дело корректно с неправильными параметрами.

5. покрытие кода.Убедитесь, что имеется по крайней мере 80% из кода работается модульными тестами.

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

Создайте первый модульного теста

Питер начинается с создания модульного теста.Он начинает с модульным тестом, поскольку он желает писать пример кода, который использует его новый класс.

Это первый модульный тест для библиотеки классов, он проверяет, поэтому он создает новый проект модульных тестов.Он открывает диалоговое окно Создать проект и выберите *** Visual C# ***, Тест, а затем Проект модульного теста.

Проект модульных теста содержит файл C#, в котором он может записывать его примере.На этом этапе он просто нужно, чтобы увидеть, как будет вызван один из его новых методов:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Fabrikam.Math.UnitTest
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        // Demonstrates how to call the method.
        public void SignatureTest()
        {
            // Create an instance:
            var math = new Fabrikam.Math.LocalMath();

            // Get a value to calculate:
            double input = 0.0;

            // Call the method:
            double actualResult = math.SquareRoot(input);

            // Use the result:
            Assert.AreEqual(0.0, actualResult);
        }
    }
}

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

Создание проекта и методы модульного теста

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

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

• Создание тестового проекта, если он еще не существует.

  • В диалоговом окне Создать проект выберите язык в качестве Visual Basic, *** Visual C++ *** или *** Visual C# ***.Выберите Тест а затем Проект модульного теста.

• Добавьте тесты в тестовый класс, который предоставляется.Каждый модульный тест один метод.

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

          [TestMethod]
          public void SignatureTest()
          {...}
  

      <TestMethod()>
      Public Sub SignatureTest()
      ...
      End Sub
  

• Каждый метод теста должен вызывать метод класса Assert, чтобы отобразить прошел ли он или терпел ошибкой.Обычно проверяется, что следует ожидать и фактический результат операции равны.

  Assert.AreEqual(expectedResult, actualResult);
  

  Assert.AreEqual(expectedResult, actualResult)
  

• Собственные методы теста могут вызывать другие обычные методы, не имеющие атрибута TestMethod.

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

  [TestClass]
  public class UnitTest1
  { ... }
  

  <TestClass()>
  Public Class UnitTest1
  ...
  End Class
  

Дополнительные сведения о создании модульных тестов в C++ см. в разделе Написание модульных тестов для языка C/C++ с использованием платформы модульного тестирования Майкрософт для C++.

Создание заглушки для нового кода

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

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

        public double SquareRoot(double p)
        {
            throw new NotImplementedException();
        }

Формирование классов и методов из тестов

Сначала создайте проект, куда нужно добавить новый класс, если она еще не существует.

Создать класс

1. Поместите курсор на примере класса требуется создать, например, LocalMath.В контекстном меню выберите команду Создать код, Создать тип.

2. В диалоговом окне Создать тип, установите Проект в проект библиотеки классов.В данном примере это Fabrikam.Math.

Создать метод

• Поместите курсор в вызове метода, например, SquareRoot.В контекстном меню выберите команду Создать код, *** Заглушки метода ***.

Выполните первый тест

Питер создает и запускает тест, нажав клавиши CTRL+R, t.Результат теста показывает, что красный индикатор сбойных и теста отображаются в списке Неудачные тесты.

Он выполняет простого изменения в код:

       public double SquareRoot(double p)
        {
            return 0.0;
        }

Он запускает тест снова и он передает:

К модульным тестам выполнения

• В меню Тест выберите Запуск, Все тесты.

  - или -

• Если обозреватель тестов открыто, выберите Запустить все.

  - или -

• Поместите курсор в файле кода тестов и нажмите клавишу *** CTRL+R, T ***.

• Если тест отображается под Неудачные тесты:

  Открыть тест, например, дважды щелкнув имя.

  Точка, в которой сбой теста отображается.

Для просмотра полного списка тестов выбирает *** Показать все ***.Чтобы вернуться в сводке выберите представление ГЛАВНАЯ.

Просмотреть сведения результата теста выбирает тест в обозревателе тестов.

Перейти к коду теста дважды щелкните тест в обозревателе тестов или выберите Открыть тест в контекстном меню.

Отладка теста открыть контекстное меню для одного или нескольких тестов, а затем выберите Отладить выбранные тесты.

Компоновка *** Выполнение тестов после построения ***Выполнять тесты в фоновом режиме при построении решения.Тесты, что ранее сбой выполняется первым.

Согласитесь интерфейс

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

Джулия, что думает примере ОДОБРЕН, но комментарии «многие функции, что тест».

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

Вместе они записывают следующий тест.

  
      [TestMethod]
        public void QuickNonZero()
        {
            // Create an instance to test:
            LocalMath math = new LocalMath();

            // Create a test input and expected value:
            var expectedResult = 4.0;
            var inputValue = expectedResult * expectedResult;

            // Run the method:
            var actualResult = math.SquareRoot(inputValue);

            // Validate the result:
            var allowableError = expectedResult/1e6;
            Assert.AreEqual(expectedResult, actualResult, allowableError,
                "{0} is not within {1} of {2}", actualResult, allowableError, expectedResult);
        }

Совет

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

Красный, зеленый, рефакторинг…

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

Красный

Питер нажимает сочетание клавиш CTRL+R, t, чтобы запустить новый тест, он создал с Джулией.После того, как он записывает любой тест, он всегда выполняется его, чтобы убедиться, что он завершается неудачей, прежде чем он пишет код, который позволяет передать.В этом практическом он выучил после его забыл задать утверждения в некоторых тестах он записал.Видеть результат происходит сбой присваивает ему доверие, если он позволяет передать результат теста правильно показывает, что требование удовлетворялось.

Другая полезная практика задать *** Выполнение тестов после построения ***.Этот параметр выполняет тесты в фоновом режиме при каждом построении решения, поэтому будет иметь постоянное отчет состояния разрешения теста кода.Питер было сначала подозрительно, он может сделать Visual Studio медленным для ответа, но он обнаруживает, что это происходит редко.

Зеленый

Питер записывает ее первая попытка в коде метода, он начинает:

    public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate;
                estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }
        

Питер выполняет тесты еще раз и все тесты проходят успешно:

Рефакторинг

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

public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate; 
                estimate = (estimate + x / estimate) / 2;
                //was: estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }

Он проверяет, что тестов по-прежнему передают:

Совет

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

… и повторение

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

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

        [TestMethod]
        public void SqRtValueRange()
        {
            LocalMath math = new LocalMath();
            for (double expectedResult = 1e-8;
                expectedResult < 1e+8;
                expectedResult = expectedResult * 3.2)
            {
                VerifyOneRootValue(math, expectedResult);
            }
        }
        private void VerifyOneRootValue(LocalMath math, double expectedResult)
        {
            double input = expectedResult * expectedResult;
            double actualResult = math.SquareRoot(input);
            Assert.AreEqual(expectedResult, actualResult, expectedResult / 1e6);
        }

Этот тест проходит при первом его выполнения.

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

Совет
Всегда создавать тест завершается неудачей, прежде чем сделать его передачи.

Исключения

Теперь Питер переходит на создание тестов для исключительных входов.

[TestMethod]
        public void RootTestNegativeInput()
        {
            LocalMath math = new LocalMath();
            try
            {
                math.SquareRoot(-10.0);
            }
            catch (ArgumentOutOfRangeException)
            {
                return;
            }
            catch
            {
                Assert.Fail("Wrong exception on negative input");
                return;
            }
            Assert.Fail("No exception on negative input");
        }

Этот тест отображается код в цикл.Он должен использовать кнопку Отмена в обозревателе тестов.Это код не завершается в течение 10 секунд.

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

        [TestMethod, Timeout(1000)]
        public void RootTestNegativeInput()
        {...

Точное время ожидания выполняет тест завершается неудачей.

Питер затем обновить код для обработки этим исключительнейшим так:

       public double SquareRoot(double x)
        {
            if (x <= 0.0) 
            {
                throw new ArgumentOutOfRangeException();
            }

Регрессия

Новый тест проходит, но регрессии.Тест, который использовался для передачи теперь завершается ошибкой:

Поиска и исправления чен ошибка:

      public double SquareRoot(double x)
        {
            if (x < 0.0)  // not <=
            {
                throw new ArgumentOutOfRangeException();
            }

После ее исправить все тесты проходят успешно:

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

Покрытие кода

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

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

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

Чтобы получить отчет о покрытии кода, в меню Тесты выберите Запуск, *** Анализировать объем протестированного кода для всех тестов ***.Затем повторно запустите все тесты еще раз.

Питер получает полный охват 86%.При его развернуть итог в отчете, это свидетельствует о том, что он имеет покрытие кода начинается с 100%.Это очень важный удовлетворительно, поскольку показатель для тестируемого кода.Расчехленные в тестах действительно сами секции.С помощью переключения кнопку Цвета отображения покрытия кода, Питер может увидеть не работались, какие части кода теста.Однако он решает, что эти разделы неважны для покрытия поскольку их в коде теста и только будут использоваться, если обнаружена ошибка.

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

При внесении?

Питер продолжить обновление кода в небольшими этапами до тех пор, пока он не сможет выполнить, что:

• Весь доступный прохождение модульных тестов.

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

• Объем протестированного кода требованиям рабочей группы.75% ultimate требование проекта.

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

• Этот код прост для понимания и расширить.

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

Принципы разработки кода с модульными тестами

Питер применяются следующие принципы при разработке кода:

• Запуск модульных тестов вместе с кодом и запустите их часто во время разработки.Модульные тесты представляют собой спецификацию компонента.

• Не выполняют тесты базовой единицы, если требования не будут изменены или тесты будут неверными.Добавьте новые тесты постепенно как расширении функциональных возможностей кода.

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

• Повтор модульные тесты вместе с кодом, так как они будут выполняться непрерывными или обычный построениями сервера.

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

Повторить изменения

Прежде чем вернуть их изменения, Питер повторно использует Lync для совместного использования его экран с его коллегаом Джулией поэтому она может неофициально и интерактивно просматривать с ним, что он создал.Тестов по-прежнему фокусом, поскольку их описание Джулия заинтересовано в основном, что код, а не как он работает.Джулия соглашается, что Питер отвечает их потребности добавления записей.

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

Питер получил уведомление, когда построение завершено.В построении в его, см. что построение выполнено успешно, и все тесты, передаваемые.

Вернуть изменения

1. В строке меню выберите Вид, Командный обозреватель.

2. В Командный обозреватель выберите Главная, а затем выберите Моя работа.

3. На странице Моя работа выберите Вернуть.

4. Просмотрите содержимое страницы Ожидающие изменения чтобы убедиться в том, что:

   • Перечисляются все необходимые изменения в Включенные изменения

   • Все нужные рабочие элементы, перечислены в Связанные рабочие элементы.

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

6. Выберите Вернуть.

Непрерывно интеграции кода

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

Дополнительные сведения см. в разделе Запуск построений, наблюдение за построениями и управление ими.

Следующие (приостановка работы, исправьте ошибку, и проводить анализ кода)