사용자 스토리에 대해 새로운 코드를 작성 합니다.
Visual Studio 응용 프로그램 수명 주기 관리 (ALM) 및 Team Foundation Server (TFS)의 새로운 사용자이십니까? 당신과 당신 팀이 응용 프로그램을 빌드하는 도구의 최신 버전에서 얻을 수 있는 최대 혜택이 궁금합니까?
그러면 몇 분 동안 이 두-장의 강의를 한 단계씩 듣고, 케이블 텔레비전과 관련된 서비스를 제공 하는 가상의 회사인 Fabrikam Fiber의 두 개발자인, 피터와 쥴리아의 하루를 따라하십시오. 체크 아웃 및 코드 업데이트, 중단 하는 경우 작업을 일시 중단, 코드 검토 요청, 변경 내용을 체크 인 및 다른 작업을 수행 하려면 Visual Studio 및 TFS를 사용 하는 방법의 예제를 볼 수 있습니다.
지금 까지의 이야기는
팀은 최근에 Visual Studio 및 Team Foundation Server 응용 프로그램 수명 주기 관리 (ALM)를 채택하기 시작했습니다. 그들은 서버 및 클라이언트 컴퓨터를 설정했고, 백로그를 만들었고, 반복을 계획했고, 앱 개발을 시작 하는 데 필요한 다른 계획을 완료했습니다.
이 장의 개요
Peter는 간략하게 그의 백로그를 검토하고 오늘 일할 작업을 선택 합니다. 그가 개발하기로 계획한 코드에 대해 단위 테스트를 작성 합니다. 일반적으로, 한 시간에 여러 번 테스트를 실행하고, 점차적으로 더 자세한 테스트를 작성 한 다음에 전달할 코드를 작성 합니다. 그는 그가 자주 쓰는 메서드를 사용하여 동료들과 자신의 코드의 인터페이스를 설명 합니다.
참고
My Work 및 코드 검사는 Visual Studio Premium 및 Visual Studio Ultimate 에서만 사용 가능 항목을 설명합니다..
항목 내용
개인 백로그를 검토하고 작업 시작을 준비하는 일
첫 번째 단위 테스트 만들기
새 코드 스텁 만들기
단위 테스트를 실행합니다.
API 일치
빨강, 녹색, 리팩터링...
코드 검사
언제 완료 됩니까?
변경 내용 체크 인
개인 백로그를 검토하고 작업 시작을 준비하는 일
팀 탐색기에서, Peter는 내 작업 페이지를 엽니다. 팀은 현재 스프린트 중 Peter가 제품 백로그에서 순위가 가장 높은 항목의 송장 상태를 평가하는 것을 일하는 데 동의했습니다. Peter는 수학 함수 구현에서 최우선 순위의 백로그 항목의 자식 작업을 시작 하기로 결정 했습니다. 그가 사용 가능한 작업 항목 목록에 진행 중인 작업 항목 & 변경 목록으로부터 일을 꺼내옵니다.
개인 백로그를 검토하기 위해 작업 시작을 준비합니다
.png "팀 탐색기의 내 작업 페이지에 있는 할 일 목록")
팀 탐색기에서 다음을 수행합니다.
작업할 팀 프로젝트에 아직 연결되어 있지 않은 경우 팀 프로젝트에 연결합니다.
.png "홈 아이콘")
홈을 선택한 다음 .png "내 작업 아이콘")
내 일을 선택합니다.
내 작업 페이지에서, 사용 가능한 작업 항목 목록에 진행 중인 작업 항목 섹션으로부터 일을 꺼내옵니다.
당신은 또한 사용 가능한 작업 항목 목록에서 일을 선택하고 시작을 선택합니다.
증분 작업 계획 초안
Peter는 일반적으로 일련의 작은 단계에서 코드를 개발합니다. 각 단계는 일반적으로 한 시간 보다 더 오래 걸리지 않고, 10분 이내로 걸릴 수도 있습니다. 각 단계에서, 그는 새 단위 테스트를 쓰고 그가 이미 작성 한 테스트 이외에 새 테스트 전달 하기 위해 개발 코드를 변경 합니다. 때로는 코드를 변경 하기 전에 새 테스트 작성하고, 때로는 코드 테스트를 작성 하기 전에 변경합니다. 때로는 그는 리팩터링합니다. 즉, 그는 새 테스트를 추가 하지 않고 코드르 개선합니다. 그가 올바르게 나타나지 않은 요구를 결정 하지 않으면 총과하는 테스트를 절대 변경 하지 않습니다.
끝에 작은 단계별로, 그는 실행할 코드의 영역에 관련된 모든 단위 테스트를 합니다. 그는 모든 테스트가 통과할 때 까지 단계 완료를 고려 하지 않습니다.
그러나, 그는 전체 작업이 끝날 때까지 Team Foundation Server 에서 코드를 확인 하지 않습니다.
Peter는 일련의 작은 단계에 대한 대략적인 계획을 기록 합니다. 그는 그가 일을 하면서 아마도 바뀔 정확한 세부와 순서를 알고 있습니다. 특정 작업에 대한 그의 최도 단계의 목록은 다음과 같습니다:
테스트 메서드 스텁 만들기ㅡ즉, 메서드의 시그니처 만들기.
특정한 일반적인 경우를 만족 합니다.
광범위한 테스트입니다. 큰 범위에 코드가 올바르게 응답 하는지 확인합니다.
음수에 대한 예외입니다. 잘못된 매개 변수를 사용하여 정상적으로 처리 합니다.
코드 검사. 단위 테스트를 통해 코드의 80% 이상이 작동 되었는지 확인 합니다.
동료 테스트 코드의 주석에서 이러한 종류의 계획을 작성합니다. 다른 사람들은 그들의 계획을 외웁니다. Peter는 작업 항목의 설명 항목에 그의 단계 목록을 적는 것이 유용한 것을 압니다. 더 긴급한 작업으로 그가 일시적으로 전환 해야 한다면, 그가 돌아갈 수 있을 때 목록을 찾는 곳을 압니다.
첫 번째 단위 테스트 만들기
Peter는 단위 테스트를 만들어 시작 합니다. 그는 그의 새 클래스를 사용 하는 코드 예제를 작성 하려고 하기 때문에 단위 테스트를 사용하여 시작 합니다.
이것은 그가 테스트하는 클래스 라이브러리를 위한 첫 단위 테스트이고, 그는 새로운 단위 테스트 프로젝트를 만듭니다. 그는 새 프로젝트 대화 상자를 열고 **Visual C#**을 선택하고 테스트를 선택한 다음, 단위 테스트 프로젝트를 선택합니다.
.png "새 프로젝트 대화 상자에서 선택한 단위 테스트")
단위 테스트 프로젝트는 그의 예제를 작성할 수 있는 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++용 Microsoft 단위 테스트 프레임워크를 사용하여 C/C++용 단위 테스트 작성을 참조하십시오.
새 코드 스텁 만들기
다음, Peter는 새 코드에 대한 클래스 라이브러리 프로젝트를 만듭니다. 단위 테스트를 위한 프로젝트와 개발 아래의 코드를 위한 프로젝트가 있습니다. 개발 중인 코드의 테스트 프로젝트로부터 프로젝트 참조를 추가합니다.
.png "테스트 및 클래스 프로젝트가 있는 솔루션 탐색기")
새 프로젝트에서, 그는 새 클래스와 성공적으로 빌드할 수 있도록 하는 메서드의 최소 버전을 추가합니다. 그것을 빠르게 할 수 있는 방법은 테스트에서 호출된 메서드 스텁과 클래스를 생성하는 것입니다.
public double SquareRoot(double p)
{
throw new NotImplementedException();
}
테스트에서 클래스 및 메서드 생성
먼저, 새 클래스를 추가하고 싶은 프로젝트를 만듭니다. (만약 존재 하지 않는다면)
클래스를 정의하려면
생성하고 싶은 클래스의 예에 커서를 위치시킵니다. 예를 들어, LocalMath. 바로 가기 메뉴에서, 코드 생성, 새 형식을 선택합니다.
새 형식 생성 대화 상자에서, 프로젝트 를 클래스 라이브러리 프로젝트로 설정합니다. 이 예제에서는, Fabrikam.Math입니다.
메서드 생성하기
- 호출할 메서드에 커서를 위치시킵니다. 예를 들어, SquareRoot. 바로 가기 메뉴에서, 코드 생성, 메서드 스텁을 선택합니다.
단위 테스트를 실행합니다.
Peter는 빌드하고 CTRL + R, T 키를 눌러 테스트를 실행 합니다. 테스트 결과는 빨간색 실패 표시기를 표시 하고 테스트 실패목록 아래 테스트가 나타납니다.
.png "실패한 테스트 1개를 보여 주는 단위 테스트 탐색기")
그는 코드를 간단히 변경합니다.
public double SquareRoot(double p)
{
return 0.0;
}
그는 테스트를 다시 실행 하고 통과합니다:
.png "통과한 테스트 1개가 있는 단위 테스트 탐색기")
단위 테스트 실행하기
.png "모두 실행 단추를 표시하는 테스트 탐색기")
테스트 메뉴에서, 단위 테스트 실행, 모든 테스트를 선택합니다.
- 또는 -
테스트 탐색기를 열면, 모두 실행을 선택합니다.
- 또는 -
테스트 코드 파일에서 커서를 위치 시키고 CTRL + R, T 를 누릅니다.
실패한 테스트에 테스트가 나타난다면:
예를 들어, 이름을 두 번 클릭 하면 테스트를 엽니다.
테스트가 실패 한 포인트가 표시 됩니다.
전체 테스트 목록을 보려면, 모두 표시를 선택합니다. 요약으로 돌아가려면 홈 뷰를 선택합니다.
테스트 결과의 세부 정보를 보려면, 탐색기 테스트에서 테스트를 선택 합니다.
테스트 코드로 이동하려면, 테스트 탐색기에서 테스트를 두 번 클릭하거나, 바로 가기 메뉴에서 테스트 열기 를 선택합니다.
테스트를 디버깅하려면, 하나 이상의 테스트에 대한 바로 가기를 열고 나서 선택한 테스트 디버그를 선택합니다.
솔루션을 빌드할 때마다 백그라운드에서 테스트를 실행 하려면 토글 테스트 빌드 후 실행. 이전에 실패한 테스트가 처음 실행 됩니다.
인터페이스 일치
Peter는 Lync에서 그의 동료 줄리아를 호출하고 그의 화면을 공유합니다. 그녀는 그의 구성 요소를 사용할 것 입니다. 그가 그의 초기 예를 보여 줍니다.
줄리아는 예제가 괜찮다고 생각하지만, "많은 기능이 테스트 전달 합니다." 라고 메모를 남깁니다.
Peter는 회신합니다, "첫 테스트는 함수의 이름 및 매개변수가 정확한지 확인하는 것입니다. 이제 우리는 이 함수의 주요 요구사항을 캡쳐하는 테스트를 적성할 수 있습니다. "
그들은 함께 다음 테스트를 작성합니다:
[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);
}
팁
이 함수에서, Peter는 첫 개발 테스트를 사용하는데 이것은 먼저 기능을 위한 단위 테스트를 작성하고, 그 다음 테스트를 만족 하는 코드를 작성 하는 것입니다.다른 경우에, 그는 이 관행이 비현실적이라는 것을 알고, 따라서 그 대신, 그는 코드 작성 후 테스트를 작성합니다.그러나 그는 단위 테스트를 작성 하는 데 그것을 매우 중요하게 고려 합니다-코드 전후에 상관없이-왜냐하면 코드를 안정적으로 유지 하기 때문입니다.
빨강, 녹색, 리팩터링...
Peter가 반복적으로 테스트를 작성 하는 확인이 실패 하면, 테스트를 통과 하는 코드를 작성 하는 주기를 따르는 다음 리팩터링을 고려 하고-즉, 테스트를 변경 하지 않고 코드를 개선 합니다.
빨강
Peter가 줄리아와 만든 새 테스트를 실행 하려면 CTRL + R, T를 누릅니다. 테스트를 작성 한 후, 전달할 코드를 작성하기 전에 실패하는 것을 확인하기 위해 테스트를 항상 실행합니다. 이것은 그가 작성한 일부 테스트에서 가정을 두는 것을 잊지 않은 후에 배운 관습입니다. 테스트를 통과하게 만들 때 실패 결과를 보는 것을 그에게 자신감을 주고, 그 테스트 결과는 요구 조건이 만족되었는지 정확하게 알려줍니다.
다른 유용한 방법은 테스트 빌드 후 실행를 설정하는 것입니다. 이 옵션은 테스트 백그라운드로 실행 솔루션을 빌드할 때마다 실행되어, 코드의 테스트 상태 보고서를 지속적으로 받을 수 있습니다. Peter는 처음에 Visual Studio 응답을 느리게 만들 것이라고 의심했지만, 드물게 일어난 다는 것을 알아냅니다.
.png "실패한 테스트 1개가 있는 단위 테스트 탐색기")
녹색
Peter는 그가 개발하고 있는 메서드의 코드를 첫 시도를 작성합니다:
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;
}
Peter는 테스트를 다시 실행하고 모든 테스트를 통과 합니다.
.png "통과한 테스트 2개가 있는 단위 테스트 탐색기")
리팩터링
주 기능을 수행 하는 코드이기 때문에, Peter는 코드를 더 잘 수행하고 미래에 변경하기 쉽게 하도록 하기 위한 관점에서 봅니다. 그는 루프에서 수행 되는 계산의 수를 줄일 수 있다는 것을 인식합니다:
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;
}
그 테스트도 통과 확인 합니다.
팁
리팩터링 또는 확장 코드를 개발 하는 동안 모두 변경되어야 합니다.
-
리팩터링 되므로 새 기능을 추가 하지 않는 테스트 변경 하지 않는 것을 의미 합니다.
-
확장은 테스트를 추가하고 기존 및 새 테스트를 통과 하는 데 필요한 코드 변경을 의미 합니다.
변경된 요구 사항에 기존 코드를 업데이트 하는 경우, 현재 요구사항을 나타내지 않는 기존 테스트를 삭제합니다.
이미 통과 된 테스트를 변경 하지 마십시오.대신에 새 테스트를 추가합니다.실제 요구 사항을 표현 하는 테스트를 작성 합니다.
변경할 때마다 테스트를 실행 합니다.
... 및 반복
Peter는 거친 가이드로 그 작은 단계 목록을 사용 하여 그의 일련의 확장 및 리팩터링 단계를 계속 합니다. 그는 항상 확장 후마다 리팩터링 단계를 수행 하지 않습니다. 때로는 둘 이상의 리팩터링 단계를 수행합니다. 하지만 그는 항상 코드에 변경을 한 후 단위 테스트를 실행합니다.
때때로 그는 코드에 변경을 요구하지 않는 테스트를 추가하지만, 그의 코드가 잘 동작하도록 그의 자신감을 추가합니다. 예를 들어, 그 함수 입력의 광범위 한 범위에 대해 작동 하는지 확인 하려고 합니다. 그가 더 많은 테스트를 작성할 때, 이와 같은 테스트를 작성합니다:
[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);
}
이 테스트는 처음 실행되면서 통과합니다:
.png "통과한 테스트 3개가 있는 단위 테스트 탐색기")
이 결과가 실수가 아닌지 확인을 위해, 그는 일시적으로 그의 테스트를 실패하도록 하는 작은 오류를 소개합니다. 실패를 본 후, 그는 다시 고칩니다.
팁
항상 통과 하는 테스트를 실패하게 만듭니다.
예외
Peter는 뛰어난 입력을 위해 테스를 작성합니다:
[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 초 안에 코드가 종료됩니다.
Peter는 빌드 서버 에서 무한 루프가 일어나지 않는지 확인 하려고 합니다. 비록 서버가 완전한 실행에서 타임아웃을 부과하지만, 이것은 상당히 긴 타임아웃이므로 상당한 지연이 발생 합니다. 따라서 그는 테스트에 명시적인 시간 제한을 추가합니다.
[TestMethod, Timeout(1000)]
public void RootTestNegativeInput()
{...
명시적 제한 시간 테스트에 실패 하면.
Peter는 예외적인 경우를 처리 하는 코드를 업데이트 합니다.
public double SquareRoot(double x)
{
if (x <= 0.0)
{
throw new ArgumentOutOfRangeException();
}
재발
새 테스트가 통과되었지만, 재발이 있습니다. 전달 하는 데 사용 되는 테스트는 이제 실패 합니다.
.png "이전에 통과한 실패한 단위 테스트")
Peter는 실수를 찾아서 설정 합니다.
public double SquareRoot(double x)
{
if (x < 0.0) // not <=
{
throw new ArgumentOutOfRangeException();
}
수정 되고, 모든 테스트는 통과합니다:
.png "통과한 테스트 4개가 있는 단위 테스트 탐색기")
팁
모든 테스트 패스 코드를 변경할 때마다 모든 테스트가 통과되는지 확인합니다.
코드 검사
그의 작업 중 일정한 간격 동안 그리고 코드를 확인하기 전 마지막으로, Peter는 코드 검사 보고서를 획득합니다. 이것은 얼마나 많은 코드가 테스트에서 실행되었는지 표시합니다.
Peter의 팀 목표는 80% 이상 검사 하는 것입니다. 이러한 종류의 코드에 대해 높은 보상을 달성 하기 어려울 수 있으므로 생성 된 코드에 대해서 이 요구를 완화 합니다.
좋은 검사는 테스트 된 구성 요소의 전체 기능 및 모든 범위의 입력된 값에 대한 코드의 작동을 보장 하지 않습니다. 그럼에도 불구하고, 코드 줄을 검사 및 컴포넌트의 동작 공간 범위 사이에 상당히 근접한 상관관계가 있습니다. 따라서, 좋은 검사는 그들이 해야할 대부분의 행동을 테스트하는 팀의 자신감을 강화합니다.
코드 검사 보고서를 가져오기 위해, 테스트 메뉴에서, 실행, 모든 테스트에 대 한 코드 검사 분석을 선택합니다. 모든 테스트를 다시 실행 합니다.
.png "코드 검사 결과 및 색 표시 단추")
Peter는 86%의 전체 범위를 가져옵니다. 보고서에 합계를 확장할 때, 그가 개발 하고 있는 코드가 100%가 검사되었다고 표시 됩니다. 테스트 대상 코드에 대한 중요한 점수 이기 때문에 매우 만족입니다. 적용 되지 않은 구역은 테스트 자체에서 실제로 합니다. 색 표시 코드 검사 지정을 토글함으로서, Peter는 실행 되지 않는 테스트 코드의 부분을 볼 수 있습니다. 그러나, 그는 테스트 코드에 오류가 검색 되는 경우에 사용할 수 있기 때문에 이 섹션에서는 중요한 검사가 없는지 결정 합니다.
코드의 특정 지점에 도달 하는지 특정 테스트를 확인 하라면, 색 표시 코드 검사 지정를 설정하고 실행 명령을 바로 가기 메뉴에서 사용함으로서 단일 테스트를 실행 합니다.
언제 완료 됩니까?
Peter는 그가 만족할 때까지 소규모에서 업데이트를 계속 합니다.
사용할 수 있는 모든 단위 테스트를 통과 합니다.
단위 테스트 집합이 매우 큰 프로젝트에서는 모두 실행 될 수 있도록 기다리는 것은 개발자에게 실용적입니다. 대신, 프로젝트는 각 체크 인 된 보류 집합에 대 한 원본 트리로 병합 전에 작동 하는 자동화된 테스트인 제어된 체크 인 서비스를 실행합니다. 실행에 실패 한 경우에 체크 인은 거부 됩니다. 이렇게 하면 개발자가 자신의 시스템에서 최소한 단위 테스트의 실행을 누른 다음 빌드가 손상의 위험을 실행 하지 않고 다른 작업을 진행 합니다. 자세한 내용은 제어된 체크 인 빌드 프로세스를 사용하여 변경 내용 유효성 검사을 참조하십시오.
코드 검사 팀의 표준을 충족합니다. 75%는 일반적인 프로젝트 요구 사항입니다.
단위 테스트의 표준 및 뛰어난 입력을 포함 하여 필요한 동작의 모든 측면을 시뮬레이션 합니다.
그의 코드는 쉽게 이해되고 확장이 쉽습니다.
이러한 모든 조건이 충족 되면, Peter는 자신의 코드를 소스 제어에 체크 합니다.
단위 테스트를 사용한 코드 개발의 원칙
Peter는 코드를 개발 하는 동안 다음과 같은 원칙을 적용 합니다.
코드와 함께 단위 테스트를 개발 하고 개발 하는 동안 자주 실행 시킵니다. 단위 테스트는 구성 요소의 사양을 나타냅니다.
요구 사항 변경 되었거나 테스트가 잘못 되었으면 단위 테스트를 변경 하지 마십시오. 코드의 기능을 확장할 때 점차적으로 새 테스트를 추가 합니다.
테스트에서 코드의 75% 이상이 다뤄지도록 목표 합니다. 소스 코드를 확인 하기 전에 정기적으로 코드 검사 결과를 살펴봅니다.
코드와 함께 단위 테스트를 체크 인하면, 그들은 연속적으로 또는 정기적으로 실행 됩니다.
실용적이고 기능적으로, 단위 테스트를 먼저 작성 합니다. 그에 맞는 코드를 개발 하기 전에 이 작업을 수행 합니다.
변경 내용 체크 인
변경을 체크하기 전에, Peter는 다시 Lync를 사용하여 그의 동료 쥴리아와 그의 화면을 공유하여 그녀가 비공식적으로 대화형으로 그가 만든 것을 검토할 수 있게 합니다. 줄리아가 코드가 어떻게 작동하는 지가 아니라 코드가 무엇인지에 주로 관심이 있기 때문에 테스트는 그들의 토론의 지속적인 초점이 됩니다. 줄리아는 피터가 그녀의 요구를 충족하는 것에 동의 합니다.
Peter는 테스트와 코드에서 그가 변경한 모든 것을 확인하고, 완료한 작업과 연결 시킵니다. 팀의 CI 빌드의 빌드 프로세스를 사용하여 자신의 변경 내용을 검사할 팀의 자동화 된 빌드 시스템을 체크 인 큐에 넣습니다. 이 빌드 프로세스는 그들의 개발 컴퓨터에서 격리된 깨끗한 환경에서 그들의 코드 베이스에서 오류를 최소화하는데 도움을 줍니다.-팀의 모든 변경 사항에서.
Peter는 빌드가 완료 된 경우에 알립니다. 빌드 결과 창에서, 그는 빌드가 성공 되는 것과 테스트가 통과되는 것을 봅니다.
변경 내용을 체크 인하려면
.png "보류 중인 변경 내용 체크 인")
메뉴 모음에서 보기, 팀 탐색기를 선택합니다.
팀 탐색기에서, 홈 을 선택한 후, 내 작업을 선택합니다.
내 작업 페이지에서, 체크 인을 선택합니다.
보류 중인 변경 내용 페이지의 콘텐츠를 검토하여 다음을 확인합니다.
관련된 모든 변경 내용이 포함된 변경 내용에 나열됩니다.
관련된 모든 작업 항목이 관련 작업 항목에 나열됩니다.
변경된 파일 및 폴더의 버전 제어 기록을 통해 팀이 이러한 변경의 목적을 이해할 수 있도록 주석을 지정합니다.
체크 인을 선택합니다.
계속 해서 코드를 통합 하기
테스트를 실행하는 빌드 프로세스를 정의하는 방법에 대한 자세한 내용은 CI 빌드 설정 항목을 참조하십시오. 이 빌드 프로세스를 설정 하면, 팀 빌드 결과 대 한 알림을 받을 수 있습니다.
.png "Peter는 CI 빌드에 성공했다는 알림을 받습니다.")
.png "CI 빌드 결과")
자세한 내용은 빌드 실행, 모니터링 및 관리를 참조하십시오.