전체 범위를 달성하기 위해 팀을 TDD로 변환 한 후 가능한 모든 테스트 사례를 작성하는 것이 좋습니까?

단위 / 기능 테스트가없는 대규모 엔터프라이즈 수준의 응용 프로그램이 있다고 가정합니다. 마감 시한이 매우 촉박하여 개발 중에 테스트 중심 개발 프로세스가 없었습니다 (확실하지 않은 마감 시한을 약속해서는 안되지만 완료된 작업은 완료되었습니다!)

모든 마감일이 지났고 상황이 안정되었으므로 모두 우리를 생산적인 TDD / BDD 기반 팀으로 전환하기로 합의했습니다.

이제 문제는 우리가 이미 가지고있는 코드에 관한 것입니다. (1) 모든 것이 완벽하게 작동하더라도 (아직도) 대부분의 개발을 중단하고 처음부터 가능한 모든 테스트 사례를 작성하는 것이 여전히 좋거나 좋은 생각입니까? ? 또는 (2) 문제가 발생할 때까지 기다린 다음 수정 중에 새 단위 테스트 작성, 또는 (3) 이전 코드를 잊고 새 코드에 대해서만 단위 테스트를 작성하고 다음 주요 리 팩터로 모든 것을 연기하는 것이 좋습니다.

몇 가지 좋은과 같은 관련 기사가 있습니다 이 하나 . 시간이 얼마 남지 않았고 다른 많은 프로젝트 / 작업이 우리를 기다리고 있다는 점을 고려할 때 이것에 투자 할 가치가 있는지 확실하지 않습니다.

참고 :이 질문은 개발 팀에서 완전히 어색한 상황을 설명 / 상상하고 있습니다. 이것은 나와 내 동료에 관한 것이 아닙니다. 상상의 상황 일뿐입니다. 이런 일이 발생하지 않아야한다고 생각하거나 개발 관리자가 그러한 혼란에 책임이 있습니다! 그러나 어쨌든 완료된 작업이 완료되었습니다. 가능하면 이런 일이 발생해서는 안된다고 생각해서 공감하지 마십시오.

매우 엄격한 마감일로 인해 개발 과정에서 테스트 중심 개발 프로세스가 없었습니다.

이 진술은 매우 중요합니다. TDD없이 개발했거나 모든 것을 테스트하지 않았기 때문이 아닙니다. 이것은 TDD가 속도를 늦추고 마감 시간을 놓칠 수 있다고 생각하기 때문에 관련이 있습니다.

이 방법으로 보는 한 TDD 준비가되지 않았습니다. TDD는 점차 완화 될 수있는 것이 아닙니다. 당신은 그것을하는 방법을 알고 있거나하지 않습니다. 당신이 그것을 반쯤 시도하면 당신은 그것을 자신과 나빠 보이게 만들 것입니다.

TDD는 집에서 먼저 연습해야하는 것입니다. 그것이 도움이 있기 때문에, 그것을 할 알아 당신에게 코드를 지금 . 누군가가 당신에게 그렇게했기 때문이 아닙니다. 나중에 변경할 때 도움이되기 때문이 아닙니다. 그것은 당신이 할 일이되면 있기 때문에 당신이 서둘러 당신은 전문적으로 그것을 할 준비가 된 것입니다.

TDD는 모든 상점 에서 할 수있는 일입니다 . 테스트 코드를 설정할 필요조차 없습니다. 다른 사람들이 테스트를 경멸하면 스스로 유지할 수 있습니다. 올바르게 수행하면 테스트를 통해 아무도 실행하지 않아도 개발 속도가 빨라집니다.

반면에 다른 사람들이 테스트를 좋아하고 실행하는 경우에도 TDD 상점에서도 테스트를 확인하는 것이 귀하의 일이 아님을 명심해야합니다. 입증 된 작업 프로덕션 코드를 작성해야합니다. 테스트가 가능하다면 깔끔합니다.

경영진이 TDD를 믿어야한다고 생각하거나 동료 코더가 테스트를 지원해야한다고 생각하면 TDD가 최선을 다하는 것을 무시하는 것입니다. 코드가 생각하는 것과 실제로하는 것의 차이점을 빠르게 보여줍니다.

그 자체만으로 마감 시간을 더 빨리 달성하는 데 도움이 될 수있는 방법을 알 수 없다면 직장에서 TDD를 준비하지 않은 것입니다. 집에서 연습해야합니다.

즉, 팀이 테스트를 사용하여 생산 코드를 읽는 데 도움을 줄 수 있고 경영진이 새로운 TDD 도구를 구입할 때 유용합니다.

팀을 TDD로 변환 한 후 가능한 모든 테스트 사례를 작성하는 것이 좋습니까?

팀의 활동에 관계없이 모든 가능한 테스트 사례를 작성하는 것이 항상 좋은 생각은 아닙니다. 가장 유용한 테스트 사례를 작성하십시오. 100 % 코드 범위는 비용이 듭니다. 판결 요청이 어렵다는 이유로 수익 감소 법을 무시하지 마십시오.

흥미로운 비즈니스 로직을 위해 테스트 에너지를 절약하십시오. 결정을 내리고 정책을 시행하는 것들. 도대체 테스트 해보십시오. 서로를 연결하는 읽기 쉬운 구조용 접착제 코드를 지루하게 만드는 것은 거의 테스트가 필요하지 않습니다.

(1) 모든 것이 완벽하게 작동하더라도 (아직도) 대부분의 개발을 중단하고 처음부터 가능한 모든 테스트 사례를 작성하는 것이 여전히 좋거나 좋은 생각입니까? 또는

아니요. 이것은 "완전히 다시 작성하겠습니다"라는 생각입니다. 이것은 어려운 지식을 파괴합니다. 경영진에게 테스트를 작성할 시간을 요구하지 마십시오. 테스트를 작성하십시오. 무엇을하고 있는지 알면 테스트 속도가 느려지지 않습니다.

(2) 문제가 발생할 때까지 기다린 다음 수정 중에 새 단위 테스트를 작성하는 것이 좋습니다.

(3) 심지어 이전 코드를 잊고 새로운 코드에 대해서만 단위 테스트를 작성하고 다음 주요 리 팩터로 모든 것을 연기합니다.

같은 방법으로 2와 3에 대답하겠습니다. 어떤 이유로 든 코드를 변경하면 테스트에 참여할 수 있다면 정말 좋습니다. 코드가 레거시이면 현재 테스트를 환영하지 않습니다. 변경하기 전에 테스트하기가 어렵다는 것을 의미합니다. 어쨌든 변경하기 때문에 테스트 가능한 것으로 변경하고 테스트 할 수 있습니다.

이것이 핵 옵션입니다. 위험합니다. 테스트없이 변경하고 있습니다. 레거시 코드를 변경하기 전에 테스트 할 수있는 몇 가지 창의적인 트릭이 있습니다. 코드를 변경하지 않고 코드의 동작을 변경할 수있는 이음새를 찾습니다. 구성 파일을 변경하고 파일을 빌드 할 수 있습니다.

Michael Feathers는 이것에 관한 책을주었습니다 : 레거시 코드로 효과적으로 작업하기 . 읽어 보시면, 새로운 것을 만들기 위해 오래된 것을 모두 태울 필요가 없다는 것을 알게 될 것입니다.

개발의 대부분을 멈추고 가능한 모든 테스트 사례를 처음부터 작성하는 것이 여전히 좋거나 좋은 생각입니까?

레거시 ¹ 코드가 주어지면 다음 상황에서 단위 테스트를 작성하십시오.

• 버그를 고칠 때
• 리팩토링 할 때
• 기존 코드에 새로운 기능을 추가 할 때

단위 테스트만큼 유용하므로 기존 ¹ 코드베이스에 대해 완전한 단위 테스트 스위트를 작성하는 것은 현실적인 아이디어가 아닙니다. 당신이 촉박 한 마감일을 전달하도록 강요된 힘. 개발하는 동안 적절한 단위 테스트를 작성할 시간이 없었습니다. "작동하는 프로그램"에 대한 테스트를 작성하기에 충분한 시간을 줄 것이라고 생각하십니까?

¹ _{레거시 코드는 단위 테스트가없는 코드입니다. 레거시 코드의 TDD 정의입니다. 레거시 코드가 새로 공급 된 경우에도 (잉크가 아직 건조되지 않은 경우에도) 적용됩니다.}

내 경험상 테스트가 도움이 되려면 전체 적용 범위가 필요하지 않습니다. 대신 보험 혜택이 증가함에 따라 다양한 혜택을 누리기 시작합니다.

• 30 % 이상의 적용 범위 (일명 두 번의 통합 테스트) : 테스트에 실패하면 문제가 발생하거나 테스트가 비정상적입니다. 고맙게도 테스트가 신속하게 경고했습니다! 그러나 릴리스에는 여전히 광범위한 수동 테스트가 필요합니다.
• 적용 범위가 90 % 이상 (일명 대부분의 구성 요소에 표면 단위 테스트가 있음) : 테스트에 통과하면 소프트웨어에 문제가 없을 수 있습니다. 테스트되지 않은 부품은 엣지 케이스이므로 중요하지 않은 소프트웨어에 적합합니다. 그러나 릴리스에는 여전히 일부 수동 테스트가 필요합니다.
• 기능 / 상태 / 지점 / 요구 사항에 대한 매우 높은 적용 범위 : TDD / BDD 꿈을 겪고 있으며 테스트는 소프트웨어의 기능을 정확하게 반영합니다. 대규모 아키텍처 변경을 포함하여 높은 신뢰도로 리팩토링 할 수 있습니다. 테스트가 통과되면 소프트웨어가 거의 릴리스 준비된 것입니다. 일부 수동 연기 테스트 만 필요합니다.

실제로 BDD로 시작하지 않으면 코딩 후에 테스트 해야하는 작업이 너무 많기 때문에 결코 거기에 갈 수 없습니다. 문제는 테스트를 작성 하는 것이 아니라 부수적 인 구현 세부 사항이 아닌 실제 요구 사항을 인식 하고 기능적이고 테스트하기 쉬운 방식으로 소프트웨어 를 설계 할 수 있다는 것입니다. 테스트를 처음 또는 코드와 함께 작성할 때는 실제로 무료입니다.

새로운 기능에는 테스트가 필요하지만 테스트에는 디자인 변경이 필요하지만 리팩토링에는 테스트가 필요하기 때문에 약간의 닭고기 및 계란 문제가 있습니다. 소프트웨어가 적절한 적용 범위에 가까워짐에 따라 새로운 기능이 테스트 될 수 있도록 새로운 기능이 발생하는 코드 부분에서 신중하게 리팩토링을 수행해야합니다. 이렇게하면 처음에 속도가 크게 느려집니다. 그러나 새로운 개발이 필요한 부분 만 리팩토링하고 테스트함으로써 테스트는 가장 필요한 부분에 중점을 둡니다. 안정적인 코드는 테스트없이 계속 진행할 수 있습니다. 버그가있는 경우 어쨌든 변경해야합니다.

TDD에 적응을 시도하는 동안 전체 프로젝트 적용 범위보다 더 나은 메트릭은 변경되는 부분의 테스트 적용 범위입니다. 리팩토링에 의해 영향을받는 코드의 모든 부분을 테스트하는 것은 불가능하지만이 범위는 처음부터 매우 높아야합니다. 또한 테스트 된 구성 요소 내에서 높은 테스트 범위의 이점을 최대한 활용할 수 있습니다. 그것은 완벽하지는 않지만 여전히 상당히 좋습니다.

단위 테스트는 일반적으로 보이지만 가장 작은 단위부터 시작하는 것은 테스트중인 레거시 소프트웨어를 얻는 데 적합한 전략이 아닙니다. 한 번에 많은 양의 소프트웨어를 실행하는 통합 테스트를 시작하려고합니다.

예를 들어 실제 로그 파일에서 통합 테스트 사례를 추출하는 것이 유용하다는 것을 알았습니다. 물론 이러한 테스트를 실행하는 데 시간이 오래 걸릴 수 있으므로 테스트를 정기적으로 실행하는 자동화 된 서버 (예 : 커밋에 의해 트리거되는 Jenkins 서버) 를 설정해야 할 수 있습니다 . 테스트 실패가 실제로 빠르게 해결된다면 그러한 서버를 설정하고 유지 관리하는 비용은 테스트를 정기적으로 실행하지 않는 것에 비해 매우 적습니다.

기존 코드에 대한 테스트를 작성하지 마십시오. 그것은 가치가 없어.

당신이 만든 것은 이미 완전히 비공식적 인 방법으로 테스트를 거쳤습니다. 당신은 손으로 끊임없이 시험해 보았습니다. 그것은 당신이 많은 버그를 찾을 수 없다는 것을 의미합니다 .

남은 것은 생각하지 못한 버그입니다. 그러나 이것들은 단위 테스트를 작성하지 않을 것이라고 생각하는 것이므로 여전히 찾지 못할 것입니다.

또한 TDD의 이유는 코드를 작성하기 전에 비트 코드의 정확한 요구 사항이 무엇인지 생각하게하는 것입니다. 다른 방법으로, 당신은 이미 그렇게했습니다.

한편, 이러한 테스트를 미리 작성하는 것만큼이나이 테스트를 작성하는 것은 여전히 ​​많은 작업입니다. 별다른 이점이 없으면 많은 시간이 소요됩니다.

그리고 코드를 작성하지 않고 버그를 거의 찾지 않고 많은 테스트를 작성하는 것은 지루 합니다. 이 작업을 시작하면 TDD를 처음 사용하는 사람들이 싫어할 것입니다.

요컨대, 개발자는 그것을 싫어하고 관리자는 많은 버그를 발견하지 않으면 서 비용이 많이 드는 것으로 간주합니다. 실제 TDD 부분에는 도달하지 않습니다.

프로세스의 일반적인 부분으로 변경하려는 항목에 사용하십시오.

테스트는 이해를 전달하는 수단입니다.

따라서 이해 한 내용에 대한 테스트 만 작성하면됩니다.

작업 할 때 무엇이 ​​참이어야하는지 이해할 수 있습니다.

따라서 작업중인 코드에 대한 테스트 만 작성하십시오.

코드로 작업하면 배울 것입니다.

따라서 배운 것을 포착하기 위해 테스트를 작성하고 다시 작성하십시오.

헹구고 반복하십시오.

코드 커버리지 도구를 테스트와 함께 실행하고 적용 범위를 줄이지 않는 메인 라인에 대한 커밋 만 수락하십시오. 결국 당신은 높은 수준의 보험에 도달하게됩니다.

한동안 코드 작업을하지 않았다면 비즈니스 결정을 내려야합니다. 이제는 팀에서 아무도 작업 방법을 모를 정도로 레거시 일 가능성이 높습니다. 아마도 구식 라이브러리 / 컴파일러 / 문서가있을 것입니다. 이는 거의 모든면에서 큰 책임입니다.

두 가지 옵션 :

1. 그것을 읽고, 배우고, 테스트를 작성하고, 리팩토링하는 시간을 투자하십시오. 자주 출시되는 소규모 변경 사항.
2. 그 소프트웨어를 버리는 방법을 찾으십시오. 어쨌든 요청할 때 수정할 수 없습니다.

(1) 모든 것이 완벽하게 작동하더라도 (아직도) 대부분의 개발을 중단하고 처음부터 가능한 모든 테스트 사례를 작성하는 것이 여전히 좋거나 좋은 생각입니까?
(2) 문제가 발생할 때까지 기다린 다음 수정 중에 새 단위 테스트를 작성하는 것이 좋습니다

테스트의 주요 목적 중 하나는 변경 사항이 아무런 영향을 미치지 않도록하는 것입니다. 이것은 3 단계 프로세스입니다.

1. 테스트가 성공했는지 확인
2. 당신을 변경
3. 테스트가 여전히 성공했는지 확인

즉, 실제로 무언가를 변경 하기 전에 작업 테스트를 받아야합니다 . 두 번째 경로를 선택하면 개발자가 코드를 만지기 전에 테스트를 작성하도록 강요해야합니다. 그리고 나는 이미 실제 변화에 직면했을 때 개발자가 유닛 테스트에 필요한 관심을 기울이지 않을 것이라고 강력히 의심합니다.

따라서 개발자가 다른 사람의 품질을 희생하지 않도록 테스트 작성 및 변경 작업을 분할하는 것이 좋습니다.

모든 것이 완벽하게 작동하더라도 (아직!)?

이것을 구체적으로 지적하기 위해 코드가 작동하지 않을 때 테스트 만하면된다는 일반적인 오해입니다. 코드가 작동 할 때 테스트가 필요합니다. 예를 들어 테스트가 아직 통과하고 있기 때문에 [새로 발생하는 버그]가 사용자의 원인이 아님을 증명하는 것입니다. 코드가 작동 중일 때 테스트가 필요하지 않다는 것을 암시 할 때 생략하는 테스트의 중요한 이점
은 이전과 마찬가지로 여전히 모든 것이 작동하는지 확인하는 것 입니다.

(3) 심지어 이전 코드를 잊고 새 코드에 대해서만 단위 테스트를 작성하고 다음 주요 리 팩터로 모든 것을 연기합니다.

이상적으로 기존의 모든 소스 코드는 이제 단위 테스트를 받아야합니다. 그러나 그렇게하기 위해 필요한 시간과 노력 (및 비용)은 단순히 특정 프로젝트와 관련이 없다는 합리적인 주장이 있습니다.
예를 들어 더 이상 개발되지 않고 더 이상 변경되지 않을 것으로 예상되는 응용 프로그램 (예 : 클라이언트가 더 이상 사용하지 않거나 클라이언트가 더 이상 클라이언트가 아닌 경우)이 코드를 더 이상 테스트하는 것이 관련이 없다고 주장 할 수 있습니다. .

그러나 선을 그리는 위치가 명확하지 않습니다. 이것은 회사가 비용 편익 분석에서 살펴 봐야 할 사항입니다. 필기 테스트는 시간과 노력이 들지만, 해당 응용 프로그램에서 향후 개발 될 것으로 예상됩니까? 단위 테스트를 통해 얻을 수있는 이익이이를 작성하는 비용보다 큽니까?

이것은 개발자로서 귀하가 결정할 수있는 결정이 아닙니다. 기껏해야 주어진 프로젝트에서 테스트를 구현하는 데 필요한 시간을 예상 할 수 있으며 실제로 프로젝트를 유지 관리 / 개발해야하는 충분한 기대가 있는지 여부를 결정하는 것은 경영진의 책임입니다.

다음 주요 리 팩터로 모든 것을 연기

다음 주요 리 팩터가 주어지면 실제로 테스트를 작성해야합니다.

그러나 중대한 변화에 직면 할 때까지 미루지 마십시오. 내 초기 포인트 (테스트 작성과 코드 업데이트를 결합하지 않음)는 여전히 유효하지만 여기에 두 번째 요점을 추가하고 싶습니다. 개발자는 현재 해당 시간을 작업하는 데 6 개월보다 더 잘 알고 있습니다. 다른 프로젝트에서. 개발자가 이미 준비 상태에있는 기간을 활용하고 향후 다시 작동하는 방식을 파악할 필요가 없습니다.

내 두 센트 :

시스템의 주요 기술 업그레이드를 기다렸다가 공식적으로 비즈니스 지원을 받아 테스트를 작성하십시오.

또는 SCRUM 상점이라고 가정 해보십시오. 작업량은 용량으로 표시되며 단위 테스트에 %를 할당 할 수는 있지만 ...

다시 돌아가서 테스트를 작성한다고 말하는 것은 순진한 것입니다. 실제로 할 일은 테스트를 작성하고 리팩토링하며 리 팩터가 코드를 더 테스트 가능하게 한 후에 더 많은 테스트를 작성하는 것이므로 시작하는 것이 가장 좋습니다. 이미 알고있는 테스트를 통해 ...

원래 작성자가 이전에 작성한 코드에 대한 테스트를 작성하고 리팩토링하는 것이 가장 좋습니다. 이상적이지는 않지만 경험상 리팩토링을 통해 코드를 더 나쁘게 만들지 않기를 원합니다.