ALM 개발자의 일상: 사용자 스토리에 대한 새 코드 작성
새 사용자의 Visual Studio 응용 프로그램 수명 주기 관리 (ALM) 및 Team Foundation Server (TFS)?팀 최대 방법 궁금해 이러한 도구를 응용 프로그램의 최신 버전에서 장점?
다음 단계에서이 두 장 자습서를 단계별로 Peter와 줄리아, 파이버 Fabrikam에 두 개발자의 생활에서 매일 수행 하는 몇 분 정도 걸릴-케이블 tv 및 관련된 서비스를 제공 하는 가상의 회사.Visual Studio 및 TFS 체크 아웃 및 코드 업데이트, 일시 중단 작업을 중단 하 고, 코드 검토 요청, 변경 내용을 체크 인할 및 다른 작업을 수행 하는 방법을 수 있습니다 예를 볼 수 있습니다.
지금까지 이야기
팀은 최근에 시작한 Visual Studio 및 Team Foundation Server 응용 프로그램 수명 주기 관리 (ALM)을 채택 하 고.해당 서버를 설정 하 고 백로그를 작성 하는 클라이언트 컴퓨터는 반복 계획 및 다른 응용 프로그램의 개발을 시작 하는 데 필요한 계획 완료.
이 장의 개요
간략하게 Peter가 백로그를 검토 하 고 저 오늘 사용할 수 있는 작업을 선택 합니다.단위 테스트 코드를 개발 하기로 그를 씁니다.일반적으로 그 시간에 여러 번의 테스트를 실행, 전달 점차 더 자세한 테스트를 작성 한 다음 해당 하는 코드를 작성 합니다.그는 자신의 코드의 인터페이스 종종 그 쓰는 메서드를 사용 하는 동료와 설명 합니다.
[!참고]
이 항목에 설명 되어 있는 내 작업 및 코드 검사 기능에만 사용할 수 있는 Visual Studio Premium 및 Visual Studio Ultimate.
항목 내용
개인 백로그 검토 및 준비 작업을 시작 하는 작업
첫 번째 단위 테스트 만들기
새 코드 스텁 만들기
첫 번째 테스트를 실행 합니다.
API를 동의 합니다.
빨강, 녹색, 리팩터링...
코드 검사
여기서 끝나면 되지?
변경 내용을 확인 합니다.
개인 백로그 검토 및 준비 작업을 시작 하는 작업
팀 탐색기를 엽니다 Peter는 내 작업 페이지.현재 스 프린트 동안 Peter 제품 백로그에 있는 최상위 우선 순위 항목 평가 송장 상태를 사용할 수 있도록, 팀 합의 했습니다.Peter 순위가 백로그 항목의 자식 작업 구현 수학 함수를 시작 하기로 결정 했습니다.이 작업에서 그를 끌는 사용 가능한 작업 항목 목록에 에서 진행 중인 작업 항목 & 변경 목록.
.gif "Hh543900.collapse_all(ko-kr,VS.110).gif")
개인 백로그를 검토 하 고 작업을 시작 하려면 작업 준비
.png "팀 탐색기의 내 작업 페이지에 있는 할 일 목록")
팀 탐색기에서 다음을 수행합니다.
작업할 팀 프로젝트에 아직 연결되어 있지 않으면 팀 프로젝트에 연결합니다.
Choose
.png "홈 아이콘")
Home, and then choose .png "내 작업 아이콘")
My Work.
에 내 작업 페이지에서 드래그 작업에서의 사용 가능한 작업 항목 목록에 에서 진행 중인 작업 항목 섹션.
작업을 선택할 수도 있습니다를 사용 가능한 작업 항목 나열 되 고 선택 시작.
증분 작업 계획 초안 작성
Peter는 일반적으로 코드는 일련의 작은 단계를 개발합니다.일반적으로 각 단계는 시간 보다 더 오래 걸리는 및 최소 10 분이 걸릴 수 없습니다.각 단계 그 새 단위 테스트를 작성 하 고 새 테스트 외에도 그는 이미 작성 된 테스트를 통과 하는 그가 개발 하는 코드를 변경 합니다.때로는 그 코드를 변경 하기 전에 새 테스트 기록 및 때로는 그 테스트를 작성 하기 전에 코드를 변경 합니다.그를 리팩터링하기 경우가 있습니다.즉, 그가 바로 코드 새 테스트를 추가 하지 않고 개선 합니다.그 결정이 요구 사항을 제대로 표시 하지 않는 경우 그 테스트를 통과 하 고, 변경 되지 않습니다.
모든 작은 단계 끝에 그 코드를이 영역에 관련 된 모든 단위 테스트를 실행 합니다.모든 테스트를 통과할 때까지 그 단계를 완전히 고려 하지 않습니다.
그러나 전체 작업이 완료 될 때까지 그 코드는 Team Foundation Server 확인 하지 않습니다.
Peter이 작은 단계의이 순서에 대 한 대략적인 계획을 씁니다.그 작업 정확한 정보와 이후 자들의 순서는 변경 된다는 것을 알고 있습니다.그의 초기 단계가 특정 작업에 대 한 목록을 다음과 같습니다.
테스트 메서드 스텁 생성-즉, 메서드의 시그니처입니다.
특정 한 일반적인 경우를 만족 합니다.
광범위 한 범위를 테스트 합니다.코드 큰 범위의 값에 제대로 응답 하는지 확인 합니다.
음수에 대 한 예외입니다.잘못 된 매개 변수를 적절 하 게 처리 합니다.
코드 검사.단위 테스트에서 코드의 80% 이상 수행 됩니다 있는지 확인 합니다.
동료 중 일부는 테스트 코드의 주석에서에서 이러한 종류의 계획 작성.다른 계획은 바로 외우.Peter 유용한 단계 자신의 목록에서 작업 항목의 설명 필드에 쓸 찾습니다.그 이상의 긴급 작업을 일시적으로 전환 해야 할 경우 그 야 수를 반환 하는 경우 목록을 제공 하는 곳을 알고 있습니다.
첫 번째 단위 테스트 만들기
Peter는 단위 테스트를 작성 하 여 시작 합니다.그가 새 클래스를 사용 하는 코드 예제를 작성 하려고 하기 때문에 단위 테스트와 함께 시작 됩니다.
그 새 단위 테스트 프로젝트를 만듭니다.이 그 테스트 클래스 라이브러리에 대 한 첫 번째 단위 테스트입니다.그 열은 새 프로젝트 대화 상자 선택 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++ 또는 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 빌드하고 T. CTRL + R을 눌러 테스트 실행목록에서 테스트 나타나고 빨간색 실패 표시기는 테스트 결과 보여 줍니다. 테스트 실패.
.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);
}
.gif "팁") 팁 |
|---|
이 함수에 대 한 Peter 테스트 처음에 저 먼저 단위 테스트는 기능에 대 한 기록 하 고 다음 테스트를 충족 하는 코드를 작성 개발, 사용 중입니다.다른 경우에는 그이 따라서 그 코드를 작성 한 후 그 테스트 작성 실제 되지 않음을 찾습니다.하지만 그가 단위 테스트 작성에 매우 중요 한 고려-앞 또는 뒤-코드를 안정적으로 유지할 수 있기 때문에. |
빨강, 녹색, 리팩터링...
Peter는 그 반복적으로 테스트를 작성 하 고 확인 실패, 테스트를 통과 하는 코드를 작성 하는 주기를 따르는 다음 리팩터링을 고려 하 고-즉, 테스트를 변경 하지 않고 코드를 개선 합니다.
빨강
Peter T 그 줄리아를 만든 새 테스트를 실행 하려면 CTRL + R을 누릅니다.그는 테스트를 쓴 후 그 항상 자신이 통과 하는 코드를 작성 하기 전에 실패 하 여 실행 됩니다.그 자신이 작성 했던 일부 테스트에서 어설션 배치 하지 않았습니다 후 그 배운 것은 좋습니다.실패 결과 보지 저 그 통과 하면 테스트 결과가 올바르게 요구 사항이 충족 되었는지 나타냅니다 자신감을 얻을 수 있습니다.
설정에 유용한 다른 방법입니다 빌드 후 실행 테스트.이 옵션은 솔루션을 빌드할 때마다 지속적인 보고서 코드의 테스트 상태를 가질 수 있도록 테스트 백그라운드에서 실행.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개가 있는 단위 테스트 탐색기")
리팩터링
코드의 main 함수를 수행 했으므로 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 기록 된 내용을 자신의 요구에 맞는 데 동의 합니다.
Peter는 그가, 모두를 포함 하 여 모든 변경에서 확인 테스트와 코드를 하 여 그 완료 된 작업과 연결 합니다.체크 인 팀의 CI 빌드 빌드 프로세스를 사용 하 여 변경 내용을 확인 하는 팀의 자동화 된 팀 빌드 시스템 큐에 넣습니다.이 빌드 프로세스에서 오류를 최소화 하는 팀 수 있습니다 자신의 빌드하고 테스트할 코드 베이스-개발 컴퓨터에서 별도 환경 정리-팀의 모든 변경.
Peter는 빌드가 완료 되 면 알림을 받게 됩니다.빌드 결과에서 창과 빌드 성공 했을 그 모든 테스트를 통과 했습니다.
변경 내용을 체크 인할 수
.png "보류 중인 변경 내용 체크 인")
메뉴 모음에서 보기, 팀 탐색기를 선택합니다.
팀 탐색기, 선택 홈 , 다음을 선택 하 고 내 작업.
에 내 작업 페이지에서 선택 체크 인.
내용을 검토는 보류 중인 변경 내용 페이지를 확인 하십시오.
모든 관련 변경 내용이 나열 된 변경 포함
모든 관련 작업 항목에 나열 된 관련 작업 항목.
지정 된 주석 팀에서 변경 된 파일 및 폴더의 버전 제어 기록을 보면 이러한 용도 알 수 있도록.
체크인을 선택합니다.
계속 하려면 코드 통합
연속 통합 빌드 프로세스를 정의 하는 방법에 대 한 자세한 내용은 연속 통합을 지원하는 빌드 프로세스 정의.이 빌드 프로세스를 설정한 후에 팀 빌드 결과 대 한 알림을 받도록 선택할 수 있습니다.
.png "Peter는 CI 빌드에 성공했다는 알림을 받습니다.")
.png "CI 빌드 결과")
자세한 내용은 빌드 실행, 모니터링 및 관리를 참조하십시오.