먹고, 자고, 호흡하는 단위 테스트/TDD/BDD [닫기]

https://stackoverflow.com/questions/1616090

06-07-2019
|

문제

API와 핵심 기능을 작성하면서 단위 테스트도 작성합니다.하지만 저는 TDD와 BDD를 먹고, 자고, 호흡하는 멋진 팬보이가 되고 싶습니다.TDD/BDD를 올바른 방법으로 시작하는 가장 좋은 방법은 무엇입니까?책, 리소스, 프레임워크, 모범 사례가 있나요?

내 환경은 여러 외부 웹 서비스 및 데이터베이스와 통합된 Grails 프런트엔드가 있는 Java 백엔드입니다.

해결책

시작하기에 좋은 곳은 블로그를 읽는 것입니다. 그런 다음 블로깅을하는 사람들의 책을 사십시오. 일부는 강력히 추천합니다.

"밥 아저씨"Martin과 Object Mentor의 사람들 :http://blog.objectmentor.com/

추신 밥을 예약하고 클린 코드 :

http://www.amazon.com/clean-code handbook-software-craftsmill/dp/0132350882

내 친구 Tim Ottinger (전물 멘토 친구)http://agileinaflash.blogspot.com/ http://agileotter.blogspot.com/

JetBrains Guys :http://www.jbrains.ca/permalink/285

다른 사람들이 TDD에 대한 의견을 제시하고 Jedi-Ninja가되기위한 탐구에 도움이되지 않기 때문에 나는 이것에 대한 확장이 필요하다고 느꼈습니다. TDD의 Michael Jordan은 Kent Beck입니다. 그는 정말로 그것에 관한 책을 썼습니다.

http://www.amazon.com/test-driven-kent-beck/dp/0321146530

그는 또한 블로그를 작성합니다.

http://www.threeriversinstitute.org/blog/?p=29

TDD의 다른 "유명한"지지자들은 다음과 같습니다.

모두를 따라야 할 훌륭한 사람들입니다. 또한 Agile 2010 또는 소프트웨어 장인 정신과 같은 일부 회의에 참석하는 것을 고려해야합니다 (올해는 시카고에서 동시에 개최되었습니다).

다른 팁

사람들이 "연습 X는 결코 나쁘지 않습니다. 작동하지 않으면 제대로하지 않습니다."라고 말하면 마음에 들지 않습니다. 죄송합니다. 다른 과도한 종교적 교리와 같은 느낌이 있습니다. 나는 그것을 사지 않는다.

나는 당신의 시간과 돈이 감당할 수있는 최고의 해결책이 목표가되어야한다고 말하는 사람들에게 동의합니다.

TDD에 반대하는 사람은 자동으로 품질을 무시한 혐의로 기소되어서는 안됩니다. ( "그래서 언제 아내를 때리는 것을 그만 두었습니까?") 사실 소프트웨어에 버그가 있고, 모든 것을 제거하는 데 드는 비용은 이익에 대비해야한다는 것입니다.

제조에서도 마찬가지입니다. 때로는 공차와 거울 마감이 보장되지 않기 때문에 표면의 치수 및 마감재의 공차는 모두 동일하지 않습니다.

예, 수업을 작성하기 전에는 종종 단위 테스트를 작성합니다. 디자인에 대한 테스트의 영향을 보았습니다. 코드 커버리지를 측정하고 시청합니다. 내 적용 범위가 허용되지 않는다는 것을 알게되면 더 많은 테스트를 작성합니다. 리팩토링을위한 단위 테스트의 안전망의 이점을 이해합니다. 나는 혜택을 직접 경험했기 때문에 혼자 일할 때도 그 관행을 따릅니다. 나는 그것을 얻었다.

그러나 나는 "식사, 수면 및 호흡 유닛 테스트 및 TDD"에 대해 나를 괴롭히기 시작한 팀원에게 물어 보는 것을 보았습니다.

내 관리자는 저에게 승진을 얻을 수있는 유일한 방법은 팀을 TDD/BDD로 데려 갈 수 있다는 것입니다.

아마도 이것이 당신을 빨기처럼 들리게한다고 생각한 적이 있습니까? 잔소리가 나머지 팀을 소외 시켰다는 것을 알았습니까?

이 응답은 몇 가지 평판 포인트를 잃을 수 있지만 말해야했습니다.

더 나은 접근 방식은 스스로 연습하고 다른 사람들이 이익을 보게하는 것이라고 생각합니다. 예를 들면. 입을 달리는 것보다 훨씬 설득력이있을 것입니다.

Geez, Grails에는 테스트 세대가 내장되어 있습니다. Grails를 사용하는 팀에서 일하고 있다면 얼마나 많은 판매가 필요합니까?

모범 사례 IMHO : 프로세스이기 때문에 실용적인 일을하십시오. 응용 프로그램 작성의 목표가 무엇인지 잊지 마십시오. 비즈니스 세계에서는 테스트를 작성하지 않습니다. 나를 잘못 이해하지 말고, 그들의 자리가 있지만, 그것은 목표가되어서는 안됩니다.

TDD/BDD를해온 사람을 찾아서 그들과 쌍을 이루는 프로그램을 찾으십시오.

메트릭은 IMHO입니다. 여기에서 거기로가는 가장 좋은 방법입니다. 코드가 얼마나 잘 적용되는지 추적하고, 모든 커밋에 대한 코드 복잡성을 유지하고, 코드를 변경하여 변경 사항을 시청하고 해당 테스트를 지속적으로 다시 실행하는 테스트 러너를 사용하십시오. 모든 도구가 잘 작동하도록 테스트 길이가 몇 줄을 넘지 않도록하십시오. 그리고 한 달에 한 번 추천합니다. 돌연변이 테스터를 통해 코드를 실행하기 위해 하루를 쉬십시오. 그날은 테스트를 작성하는 데 전념해야합니다. 당신이 아직 좋은 TDD를하고 있지 않다면이 모든 것들이 당신에게 고통을 가져올 것입니다. 고통으로부터 배우고 전혀 시간이 지남에 따라 올바른 일을 할 것입니다.

원하는 행동을 설명하기 위해 테스트가 무엇인지 시야를 잃지 마십시오. 그들은 당신의 실행 가능한 사양입니다. (이것이 내가 좋아하는 이유이기도합니다 오이; 이제 PHB가 테스트를 작성하도록 할 수 있습니다! 글쎄, 아마도 그렇게 좋지는 않지만 가깝습니다!)

"PS : 내 관리자는 팀을 TDD/BDD로 데려 갈 수있는 유일한 방법은 나에게 홍보 할 수있는 유일한 방법이라고 말합니다."

팀이 (과정에서 당신을 죽이지 않고) 무언가를하도록하는 유일한 현실적인 방법은 습관을 바꾸는 데 도움이 될 것임을 분명히 보여주는 것입니다. 다시 말해, 코드를 작성하십시오. 많은 코드. 수많은 코드. 그런 다음 사양을 근본적으로 변경하는 중요한 이메일이 도착하면 리팩토링으로 코드를 쉽게 변경할 수 있고 더 나쁜 것이 있음을 보여줍니다. 준비 테스트를 마련했습니다. 바는 녹색, 해킹 핵 해킹, 레드 바 !!!

Test Driven Design에 대한 Kent Becks Book을 읽으십시오. 테스트로 시작한 다음 코드를 수행하십시오. 테스트를 실행하는 빌드 서버를 실행하십시오! 당신은 팀 전체를 위해 그것을 가지고 있지 않아야합니다 - 스스로를 위해 그것을하고 그것이 도움이된다는 것을 보여주십시오.

설교만이 원주민을 괴롭 힙니다 :)

나는 몇 년 동안 TDD를 해왔지만 최근에는 디자인과 개발을 주도하는 BDD 방식을 더 많이 찾기 시작했습니다. BDD를 시작하는 데 도움이 된 리소스는 Formost Dan North의 블로그 (BDD의 '창립자')였습니다. 보세요 BDD 소개. '공식'BDD 위키도 있습니다. 행동 -driven.org 읽을 가치가있는 좋은 게시물로.

BDD로 시작할 때 실제로 열심히 찾은 것은 (그리고 여전히 조금 어렵다는 점)는 BDD에 적합하게하기 위해 이러한 시나리오를 공식화하는 방법입니다. Scott Bellware는 BDD (또는 그가 동전을 좋아하는 상황에 맞는)와 그의 기사에 능숙한 사람입니다. 행동 중심의 개발 Code Magazine에서 BDD 사고 방식을 이해하고 사용자 스토리를 공식화하는 데 많은 도움이되었습니다.

나는 또한 Tekpub Screencast를 추천 할 것입니다 Specflow를 사용한 동작 중심 디자인 Rob Conery에 의해. C#에서 BDD를 수행하는 데 매우 적합한 BDD 및 도구 (Specflow)에 대한 훌륭한 소개.

TDD 리소스는 이미 많은 좋은 권장 사항이 있습니다. 그러나 나는 단지 내가 정말로 추천 할 수있는 몇 권의 책을 지적하고 싶습니다.

레거시 코드로 효과적으로 작동합니다 마이클 깃털에 의해; 레거시 코드를 작업하고 있다면 (우리 모두가 아닌가?) 테스트중인 것을 원한다면 필수 읽기 읽기
단위 테스트의 기술 : .NET의 예제와 함께 Roy Osherove; 단위 테스트를 처음 접한다면 이것이입니다 그만큼 시작하려면 예약하십시오
테스트 중심 개발 : 예에 따라 켄트 벡; 당신이 TDD를 배우고 있다면 왜 소스 자체에서 그것을 얻지 않겠습니까? 좋은 책 - 읽기 쉬운, 좋은 유머와 훌륭한 생각.
클린 코드 : 민첩한 소프트웨어 장인 핸드북 Robert C. Martin; 켄트 벡이 어떻게 TDD의 밥 삼촌은 다음을 설명합니다 WHOYS.

시작을 위해 단위 테스트를 위해, 마지막으로 수행하는 방법에 대해 읽으십시오. 마지막으로 팀에 TDD를하는 방법을 가르치고 타는 방법을 가르치십시오. 내 경험상 전체 팀과의 단위 테스트를 수행하는 것이 더 중요하지 않기 때문입니다.

또한 코드를 빌드하고 Testst를 실행하는 빌드 서버를 사용하여 TeamCity (제한 사항이있는 무료)를 사용하는 것이 좋습니다.

좋은 단위 테스트를 바로 잡는 방법을 배우는 것은 어려운 부분입니다. 일부는 단위 테스트를 유지하는 한 스스로 배울 수 있으며 인터넷 검색에서 배울 수있는 나머지는 스스로 배울 수 있습니다.

개발의 일환으로 단위 테스트를 작성하지 않을 때 목표에 도달했을 것임을 알게 될 것입니다.

Agile은 특정 방법으로 완전히 매진되지 않았다는 것을 의미합니다. 스윙 인터페이스에서 시행 착오 편집을하는 것과 같이 TDD의 이점이 가치가없는 곳에서 작업하고 있다면 TDD를 사용하지 마십시오.

나는 아무도 TDD가 ~ 아니다 테스트에 대해. TDD-ing은 작은 행동 변화 수정을 수행하기 전에 예상되는 동작을 표현하는 것입니다. 이것은 디자인을 크게 향상시키고 이전에 경험 한 적이없는 방식으로 집중할 수있게합니다. 미래의 리팩토링을 보호하는 테스트와 90%의 적용 범위를 무료로 얻을 수 있습니다.

그것을 배우기 위해 나는 제안 할 것입니다 (다른 사람들이 말한 것을 요약하고 내 자신의 것 중 하나를 추가) :

블로그를 방문하여 위에서 언급 한 책을 읽으십시오
TDD에 능숙한 사람과 짝을 이루십시오
관행

나는 빛을보기 시작하기 전에 볼링 카타 (운동)를 약 20 번 (약 30 분) 연습했습니다. 밥 삼촌의 설명을 분석하여 시작 여기. Codingdojo.org 사이트에는 솔루션 및 토론을 포함하여 수많은 Katas가 있습니다. 시도해보십시오!

Nike의 인용문을 받으려면 : 그냥하십시오.

두 번째 조언 - 다른 사람의 인터페이스에 의존하지 마십시오. 항상 각 클래스 수준에서 당신이 원했던 인터페이스에 항상 쓰십시오. 필요에 따라 실제 구현에 어댑터를 작성하십시오.

또한 메소드의 리턴 값을 피하고 함수 호출보다는 메시지 통과 측면에서 코드를 생각하는 것이 유용하다고 생각합니다.

ymmv.

1년 전에는 TDD를 수행하는 방법을 거의 몰랐고(하지만 정말 하고 싶었고(얼마나 실망스러웠는지)) BDD에 대해 들어본 적도 없었습니다.이제 나는 두 가지를 모두 강박적으로 수행합니다.나는 Java가 아닌 .Net 개발 환경에 있었지만 기능/시나리오 또는 사양인지에 따라 Cucumber(BDD) 또는 MBUnit(TDD)을 실행하기 위해 "F5 - 실행" 버튼을 매크로로 대체하기도 했습니다.가능하다면 디버거가 없습니다.디버거를 사용하는 경우(농담(일종의)) 항아리에 $1.

그 과정이 아주 굉장해요.우리가 추가로 사용하고 있는 프레임워크는 제가 축복받은 Oracle을 통해 정보를 흡수하고 있으며 그가 사용하는 프레임워크는 MavenThought입니다.

모든 것은 BDD에서 시작됩니다.우리 BDD는 철 루비 위에 곧은 오이입니다.

특징:

대본:....내가 하니까 어쩌구...
다른 일을 하다가...그러다가 놀라운 일이 일어납니다...

대본:...

그리고 그것은 단위 테스트 자체가 아니라 기능, 시나리오별 시나리오, 그리고 단위(테스트) 사양을 구동합니다.따라서 시나리오에서 시작하고 시나리오에서 완료해야 하는 각 단계를 통해 TDD가 구동됩니다.

그리고 우리가 사용해 온 TDD는 일종의 BDD입니다. 왜냐하면 우리는 SUT(System Under Test)가 요구하는 동작을 살펴보고 사양(클래스 "테스트" 파일)별로 하나의 동작이 지정되기 때문입니다.

예:

다음은 하나의 동작에 대한 사양입니다.테스트 중인 시스템이 생성될 때.

속성이 변경될 때의 또 다른 동작에 대한 사양(C# When_blah_happens 클래스 파일)이 하나 더 있지만 이는 별도의 파일로 분리되어 있습니다.

using MavenThought.Commons.Testing;
using SharpTestsEx;

namespace Price.Displacement.Module.Designer.Tests.Model.Observers
{
    /// <summary>
    /// Specification when diffuser observer is created
    /// </summary>
    [ConstructorSpecification]
    public class When_diffuser_observer_is_created
        : DiffuserObserverSpecification
    {
        /// <summary>
        /// Checks the diffuser injection
        /// </summary>
        [It]
        public void Should_return_the_injected_diffuser()
        {
            Sut.Diffuser.Should().Be.SameInstanceAs(this.ConcreteDiffuser);
        }
    }
}

이는 아마도 SUT의 가장 간단한 동작일 것입니다. 왜냐하면 이 경우 생성될 때 Diffuser 속성은 주입된 디퓨저와 동일해야 하기 때문입니다.이 경우 Diffuser는 Core/Domain 객체이고 인터페이스에 대한 속성 알림이 없기 때문에 Mock 대신 Concrete Diffuser를 사용해야 했습니다.95%의 시간 동안 실제 항목을 주입하는 대신 Dep()와 같은 모든 종속성을 참조합니다.

종종 우리는 하나 이상의 [It] Should_do_xyz()를 갖고 때로는 최대 10줄의 스터빙과 같은 상당한 설정을 갖기도 합니다.이는 해당 사양에 GiveThat() 또는 AndGivenThatAfterCreated()가 없는 매우 간단한 예입니다.

각 사양을 설정하려면 일반적으로 사양의 몇 가지 메서드만 재정의하면 됩니다.

GiveThat() ==> 이는 SUT가 생성되기 전에 발생합니다.

CreatSut() ==> StructureMap을 사용하여 sut의 자동 모의 생성을 자동으로 모의하며 90%의 시간 동안 이를 재정의할 필요가 없습니다. 그러나 콘크리트를 주입하는 생성자라면 이를 재정의해야 합니다.

AndGivenThatAfterCreated() => 이는 SUT가 생성된 후에 발생합니다.

WhenIRun() => [ConstructorSpecification]이 아닌 한 이를 사용하여 SUT에 대해 지정하는 동작인 한 줄의 코드를 실행합니다.

또한 동일한 SUT의 두 개 이상의 사양에 공통된 동작이 있는 경우 이를 기본 사양으로 옮깁니다.

사양을 실행하기 위해 해야 할 일은 이름을 강조 표시하는 것뿐입니다(예: "When_diffuser_observer_is_created"). 그리고 F5를 누르는 것뿐입니다. 왜냐하면 F5는 Rake 작업을 test:feature[tag] if Cucumber 또는 test:class[SUT]로 실행하기 때문입니다.디버거를 실행할 때마다 코드가 생성되지 않기 때문에 이해가 됩니다(아 그리고 비용은 $1(농담)입니다).

이는 TDD로 동작을 지정하고 정말 간단한 SUT와 간단한 사양을 갖는 매우 깔끔한 방법입니다.만약 당신이 카우보이 코더가 되어 하드 의존성 등으로 형편없는 SUT를 작성하려고 한다면, TDD를 시도하고 지치거나 포기하거나 총알을 깨물고 올바르게 수행하는 고통을 느낄 것입니다.

그리고 여기에 실제 SUT가 있습니다.우리는 약간의 멋을 갖고 PostSharp를 사용하여 Diffuser에서 변경된 속성 알림을 추가하므로 Post.Cast<>가 됩니다.그리고 이것이 바로 제가 Mock 대신 Concrete를 주입한 이유입니다.어쨌든, 다른 사양에 정의된 누락된 동작은 디퓨저에서 변경 사항이 있을 때 발생합니다.

using System.ComponentModel;
using MavenThought.Commons.Events;
using PostSharp;
using Price.Displacement.Core.Products;
using Price.Displacement.Domain;

namespace Price.Displacement.Desktop.Module.Designer.Model.Observers
{
    /// <summary>
    /// Implementation of current observer for the selected product
    /// </summary>
    public class DiffuserObserver : AbstractNotifyPropertyChanged, IDiffuserObserver
    {
        /// <summary>
        /// gets the diffuser
        /// </summary>
        public IDiffuser Diffuser { get; private set; }

        /// <summary>
        /// Initialize with a diffuser
        /// </summary>
        /// <param name="diffuser">The diffuser to observe</param>
        public void Initialize(IDiffuser diffuser)
        {
            this.Diffuser = diffuser;
            this.NotifyInterface().PropertyChanged += (x, e) => this.OnPropertyChanged(e.PropertyName);
        }

        /// <summary>
        /// Gets the notify interface to use
        /// </summary>
        /// <returns>The instance of notify property changed interface</returns>
        protected INotifyPropertyChanged NotifyInterface()
        {
            return Post.Cast<Diffuser, INotifyPropertyChanged>((Diffuser)Diffuser);
        }
    }
}

결론적으로 이러한 BDD/TDD 스타일의 개발은 흔들립니다.1년이 걸렸지만 나는 삶의 방식으로 완전히 개종했습니다.나는 이것을 혼자서 배우지 않았을 것입니다.The Oracle에서 모든 것을 가져왔습니다. http://orthocoders.com/.

빨간색 알약, 파란색 알약, 선택은 당신의 몫입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow