TDD로 새 프로젝트 시작

TDD를 공부하고 있는데 앱의 디자인을 정의하는 데 도움이된다는 것을 읽었습니다. 맞습니까?

그래서 더 잘 이해할 수 있도록 새 프로젝트를 만들기 시작했습니다.

이름, 이메일 주소, 국가 (목록에서 하나를 선택합니다) 및 전화 번호를 묻는 간단한 사용자 등록 시스템을 만들고 싶습니다.

질문은 ...

VS 2010에서 새 솔루션을 만들고 새 테스트 프로젝트를 추가했는데 어떤 테스트를 작성해야할지 모르겠습니다!

디자인을 정의하는 데 도움이되므로 여기서 어떤 테스트를 작성할 수 있습니까?

도움을 주셔서 감사합니다!

단위 테스트를 작성할 때 응용 프로그램의 동작을 테스트하므로 중요한 질문은 응용 프로그램의 기능입니다 . 시작은 다음과 같습니다.

[TestFixture]
public class RegistrationTests
{
    [Test]
    public void Should_save_new_user_info()
    {
    }

    [Test]
    public void Should_throw_validation_exception_when_email_already_exists()
    {
    }

    [Test]
    public void Should_format_phone_number_when_country_code_is_us()
    {
    }
}

테스트 프로젝트를 만들고 일부 테스트 메소드를 작성하는 것은 일종의 TDD이지만 내 경험상 알려진 API가 있고 라이브러리가 사용자가 기대하는 것과 직접 일치하는 라이브러리에서 작업하지 않는 한 큰 도움이되지 않습니다. . 올바른 테스트 목록을 작성하고 사소한 응용 프로그램의 경우 실제로 수행하기가 어려울 수 있습니다.

SpecFlow를 사용하는 것이 좋습니다. 테스트 정의를 구현과 별도로 분리하고 기능 파일의 구조를 사용하면 실제로 테스트중인 대상에 대해 생각하게됩니다.

기능을 정의하면 다음과 같이 작성하면됩니다.

When a user is saved
Then the user should exist

지금은 코드 파일이 아니기 때문에 사용자를 생성하기 위해 어떤 메소드를 호출하는지 또는 어떤 클래스를 구현했는지와 같은 구현 세부 정보에 대해 생각하지 않아도됩니다. 태그를 사용하여 다른 구현을 선택할 수 있습니다. 따라서이 수준에서 "사용자 저장 여부"는 CreateUser에 대한 호출 또는 브라우저 열기 및 양식 제출을 의미하지 않습니다.

기능이 정의되면 모든 테스트가 생성되고 단계 정의 및 테스트중인 실제 애플리케이션 코드를 구현할 때 통과하기 시작합니다.

간단한 응용 프로그램의 경우 기능 파일 만 만들 수 있지만 더 복잡한 작업의 경우 더 완벽한 사양을 미리 정리하는 것이 좋습니다. 나는 이것을 위해 iPad 마인드 매핑 응용 프로그램을 사용하지만 가장 편한 도구를 사용할 수 있습니다.

"사용자 등록"과 같은 고급 기능 목록으로 시작하십시오. 이들은 직접 테스트하기에는 너무 광범위하므로 명확하게 정의 할 수있는 하위 기능으로 분류하고 일반적으로 "사용자 저장"또는 "기존 사용자보기"와 같은 특정 사용자 작업에 매핑합니다.

이러한 각 하위 기능에는 "유효한 사용자를 저장할 수 있습니다"및 "사용자 이름이 중복 된 사용자를 저장할 수 없습니다"와 같이 기능이 작동하는지 여부를 완전히 정의하는 시나리오 목록이 필요합니다.

이 목록을 작성할 때 일반적으로 구조를 조정해야하는 위치가 명확 해집니다. 기능에 대한 시나리오 테스트를 수행 할 수 없거나 하나의 기능에 너무 많은 결과가 발생하면 해당 기능은 잘못된 레벨이며 분할 또는 변경해야합니다.

첫 번째 실험을 약간의 판독 및 절단 코드로 TDD에 백업하는 것이 좋습니다. 이 주제에 관한 wikipedia 기사 는 매우 훌륭하며 다양한 다른 자료를 제공합니다. 특히 켄트 벡이 TDD의 아버지를 찾아보십시오.

당신이 그것의 스윙에 도움이 될 수있는 또 다른 것들은 간단하고 거의 정신이없는 훈련 연습 인 katas를하는 것입니다. Roy Osherove 는 좋은 것들이 있습니다.

그 외에도 TDD의 핵심 아이디어를 명심하십시오-한 번에 하나의 테스트를 작성하고 테스트와 이전의 모든 테스트가 통과 할 때까지 계속하지 마십시오. 현재 테스트를 만족시키기에 충분한 코드 만 작성하십시오. 더 많은 유혹을 피하십시오. 갈 때마다 반복해서 멈추고 코드 나 테스트를 정리할 수 있는지 생각하십시오. 항상 빨간색 (실패 테스트), 녹색 (통과 테스트), 리 팩터 사이클로 개발하십시오.

그리고 시작하려면 이름 요구 사항부터 시작하십시오. 무엇을 원하십니까?

아마 수업이 필요할 것입니다. 그것에 대한 테스트를 작성하고 (일부 사람들은 이것을 건너 뛰지 만 시작할 때 연습을 위해) 수업을 씁니다.

다음으로 수업에 이름을 저장해야합니다. 수업이 실제로 할 수 있음을 증명하는 시험을 작성하십시오. 그런 다음 테스트를 통과하기위한 코드를 다시 작성하십시오.

그런 다음 비즈니스 규칙이 더있을 수 있습니다. 아마도 당신은 당신의 이름이 최소 문자 수를 원할 것입니다. 테스트 작성, 실패 참조, 코드 작성

등등...

짧은 답변으로 TDD에 대한 아이디어를 줄 수는 없다고 생각합니다. 당신은 그것을 느끼기 위해 그것을 수행하는 sombody를 "보아야"합니다. 그 주제에 대해 내가 찾은 최고의 리소스는 http://pragprog.com/titles/achbd/the-rspec-book 입니다. 루비는 당신의 언어가 아닙니다 : 밥 아저씨의 서문을 읽으십시오! ;-)

이메일 필드에 여러 가지 다른 값을 추가하려고 시도하는 테스트를 설정할 수 있습니다. 일부는 유효하고 다른 값은 아닙니다. 모든 테스트가 예상 값을 제공 할 때까지 개발을 중단하지 마십시오. 그런 것들.

시스템을 설명했듯이 응용 프로그램 수준에는 단 하나의 테스트 만 있습니다.

[Test] public void Save_and_retrieve_user (문자열 이름, 문자열 이메일, ...) {// 저장 // 검색 // 확인}

요구 사항을 세분화할수록 더 많은 테스트를 추가하십시오.