TDD를 가르칠 때 전달해야 할 가장 중요한 것 [닫기]

Question

저는 전문가 그룹과 협력하여 관심은 있지만 경험이 없는 사람들(초심자)에게 TDD 실습을 가르치는 데 도움이 되는 이벤트를 개최하고 있습니다.

우리는 실험실, 워크샵 등을 마련하려고 노력하고 있으며 앞으로 TDD를 성공적으로 실천할 수 있도록 이들 개인에게 전달해야 할 가장 큰 단일 사항을 생각하려고 노력하고 있습니다.

우리가 학습에 있어 무엇을 우선시해야 한다고 말하겠습니까?TDD 교육의 어떤 측면이 그만큼 가장 중요한.두 가지 일을 해야 한다면 괜찮습니다. 단일 부분에만 매달리지 않겠습니다 :)

Answer 1

디자인에 관한 것입니다.그것은 아니다 테스트에 대해.

Answer 2

프로세스의 단계를 건너뛰지 마십시오.TDD의 초기 단계에 진입하는 데 시간이 더 걸리지만, 일단 설치되면 전체 SDLC가 더 빠르고 버그가 훨씬 더 많아집니다.

빨간색 - 녹색 - 리팩터링 -> 그냥 하세요.

Answer 3

테스트를 통과했다고 해서 코드가 정확하다는 의미는 아닙니다.

그 외에도 디자인에서 테스트를 고려하는 것이 중요하다고 말하고 싶습니다.테스트 중인 장치의 내부 구현에 대한 자세한 지식 없이 코드를 테스트하기 어려운 경우 디자인을 다시 고려하는 것이 좋습니다.그렇지 않으면 코드에 따라 테스트를 변경해야 하므로 리팩토링이 더 위험해집니다.

Answer 4

이것이 가장 중요한 단일 사항으로 간주될지는 모르겠지만, TDD를 사용하여 처음 탐색할 때 "얻는" 데 시간이 좀 걸렸습니다.

테스트를 작성하기 전에 머릿속으로 코드를 작성하지 마세요.

처음 TDD를 시작했을 때 나는 디자인이 무엇인지 "알고 있었습니다".나는 내가 작성하고 싶은 코드가 무엇인지 "알고" 있었습니다.그래서 저는 해당 코드를 작성할 수 있는 테스트를 작성했습니다.

내가 이 일을 하고 있었을 때 나는 실제로 TDD를 하고 있지 않았습니다. 왜냐하면 코드를 먼저 작성했기 때문입니다(비록 코드가 내 머릿속에만 있었음에도 불구하고 :-)

테스트에 집중해야 한다는 사실을 깨닫는 데는 시간이 좀 걸렸습니다.원하는 동작에 대한 테스트를 작성한 다음 이를 통과하는 데 필요한 최소한의 코드를 작성한 다음 리팩토링을 통해 디자인이 나타나도록 하세요.완료될 때까지 반복합니다.

Answer 5

"인내심을 가지십시오"라고 제안합니다. 처음에는 이상하게 느껴집니다.나에게는 그것이 자연스럽게 느껴지기 전에 아마도 세 개의 프로젝트가 있었을 것입니다.

Answer 6

나는 무엇에 동의한다 Jon은 그의 대답에서 이렇게 말했습니다., 그러나 중요한 결과는 테스트 가능성이 지시하지 않는다는 것입니다. "좋은 디자인", 그러나 이는 귀하의 디자인이 목표에 부합한다는 지표일 뿐입니다.

Answer 7

내 생각에 TDD는 리듬(빨간색, 녹색, 리팩토링)에 관한 것입니다.리듬을 낮추면 "이해하지 못함"이라는 "고비"를 극복할 수 있습니다.그리고 리듬을 늦추지 않으면 TDD를 오랫동안 고수하지 못할 가능성이 높습니다.리듬의 본질은 이미 언급한 베이비 스텝이다.가능한 한 적은 코드를 작성하고 무자비하게 리팩토링하세요.

한 가지 강조하다 TDD는 단기적인 이익을 장기적인 이익으로 교환한다는 것입니다.TDD로 시작하면 항상 생산성이 저하됩니다.하지만 일단 리듬을 배우면 그루브에 빠져드는 것과 비슷하며 실제로 작업 속도를 높이는 데 도움이 될 수 있습니다.TDD의 부작용은 말할 것도 없이 회귀 테스트를 제공하는 단위 테스트의 기반이 계속 커지고 있다는 것입니다.소프트웨어의 불가피한 점 중 하나는 자동화된 회귀 테스트 없이 유지 관리되는 시스템이 시간이 지남에 따라 성능이 저하된다는 것입니다.

Answer 8

TDD는 개발자를 위한 패러다임 전환임을 강조합니다.에스.새로운 팀을 구성하는 경우 팀이 TDD 실무자로서 완전히 효과적으로 작동하려면 최대 6개월이 소요된다는 점을 인식하세요.TDD를 효과적으로 연습하는 성숙한 애자일 팀이 있으면 페어링을 통해 새로운 개발자가 몇 번의 반복 후에 작업을 시작할 수 있습니다.또한 한 팀의 쌍을 사용하여 새 라인을 시드하면 새 라인이 첫 번째 라인보다 훨씬 빠르게 TDD 속도를 낼 수 있습니다.

우리가 측정한 프로젝트에서 팀이 TDD를 배운 후 자동화된 기능/회귀 테스트 중에 발견된 결함이 6배 감소한 것을 확인했습니다.이는 상당한 비용 절감입니다.또한 코드는 각 기능에 대한 코드 줄이 적어 더욱 깔끔한 디자인을 반영합니다.TDD이지만 금도금은 사실상 중단되었습니다.TDD는 스토리 카드에 승인 기준이 있는 경우 가장 효과적입니다.

TDD는 또한 지속 가능한 속도를 가능하게 합니다.팀은 코드가 결함이 거의 없이 깨끗하게 유지되기 때문에 각 반복마다 동일한 수의 기능을 계속 수행할 수 있다는 것을 알게 될 것입니다.TDD와 자동화된 기능/회귀 테스트를 모두 사용하면 사용자 승인 테스트 중에 결함이 전혀 발견되지 않는 경우가 많습니다.

Answer 9

마감 기한이 촉박할 때 TDD를 버려야 한다는 압박감에 대처합니다.이것은 내가 TDD를 사용하는 사람들과 팀을 도우면서 겪게 된 가장 큰 문제 중 하나입니다.그들은 더 높은 경영진에게 테스트 대신 기능을 제공하는 것의 중요성과 가치를 표현하는 데 어려움을 겪었습니다.

Answer 10

아기 단계로 진행하십시오.

테스트가 매우 작은 범위에만 적용되는지 확인하고 PhlipCPP가 말한 대로:'테스트를 통과하는 데 필요한 최소한의 편집을 수행합니다.'

그럼에도 불구하고 TDD에는 많은 내용이 있으므로 여전히 아무것도 놓치지 않도록 해야 합니다.

Answer 11

내 경험에 따르면, TDD를 사용하면 나와 우리 팀은 예상치 못한 문제가 발생할 것이라는 걱정 없이 코드를 무자비하게 리팩토링할 수 있습니다.

따라서 TDD의 가장 중요한 측면은 적용 범위라고 생각합니다. 좋은 적용 범위는 코드 베이스에서 이를 사용할 수 있는 지점을 볼 때마다 리팩토링할 수 있다는 자신감을 주기 때문입니다.

Answer 12

다양한 종류의 테스트를 강조합니다.블랙박스 테스트와 화이트박스 테스트는 모두 중요하며 목적이 다릅니다.화이트박스 테스트는 전체 시스템을 테스트할 수 없기 때문에 정확성을 검증하기 위한 것이 아닙니다.코드 냄새를 더욱 악취나게 만들고 더 나은 리팩토링 방향을 제공하기 위해 존재합니다.블랙박스 테스트는 정확성을 테스트하기 위해 존재합니다.모든 기능은 블랙박스 테스트를 거쳐야 합니다.

또한 테스트 범위의 차이점을 강조하세요.조합 및 반복성 문제로 인해 애플리케이션의 모든 코드 경로를 블랙박스 테스트하는 것은 불가능합니다.내 규칙은 블랙박스 테스트를 거치기 전까지는 기능이 완성되지 않는다는 것입니다.학생들이 자신만의 규칙을 찾아내도록 도와주어야 합니다.그러나 화이트박스 테스트에는 외부 클래스 종속성이 없어야 합니다.그러므로 모든 클래스의 모든 라인은 화이트박스 테스트를 거쳐야 합니다.