GitHub Copilot을 사용하여 회사에서 테스트 검사 늘리기

기능을 이해하고, 개발자를 지원하고, Copilot의 영향을 측정합니다.

누가 이 기능을 사용할 수 있나요?

GitHub Copilot Business or GitHub Copilot Enterprise

이 문서의 내용

이 가이드는 엔지니어링 시스템 개선을 위한 전략과 측정 항목을 추천하는 GitHub의 ESSP(엔지니어링 시스템 성공 플레이북)에서 영감을 받았습니다.

Copilot을 출시하려면 목표를 정의하고, 이에 따라 출시를 계획하고, 직원에게 목표를 명확하게 전달하는 것이 좋습니다. GitHub Copilot을 사용하여 회사의 엔지니어링 목표 달성을(를) 참조하세요.

1. 성공을 가로막는 장애 요인 식별

ESSP에서 권장하는 첫 번째 단계는 회사의 개선을 방해하는 장애물을 명확히 이해하는 것입니다. 현재 기준, 원하는 미래 상태, 진행을 방해하는 장벽을 이해하게 되면 발생하는 변화의 방향이 목표 지향적이고 효과적이라는 것을 확신할 수 있습니다.

많은 소프트웨어 팀은 부족한 단위 테스트 검사로 인해 고품질 코드를 유지하는 데 지속적인 어려움을 겪습니다. 빠르게 진행되는 개발 환경에서 테스트를 작성하는 일은 시간이 많이 걸리거나 필수적인 작업은 아닌 것으로 간주되며, 특히 팀이 기능을 신속하게 제공해야 한다는 압박을 받고 있는 경우에 더욱 그렇습니다.

따라서 개발 수명 주기 후반에 스테이징 또는 프로덕션 환경에서 중요한 버그가 발견될 수 있습니다.

이로 인해 다음과 같은 부정적인 연쇄 결과가 발생합니다.

  • 버그 비율 및 고객이 보고한 이슈 증가
  • 배포 후 버그 수정 비용 증가
  • 코드 안정성에 대한 개발자 신뢰도 감소
  • 반응성 디버깅 및 패치로 인한 느린 릴리스 주기

레거시 시스템에서는 복잡한 종속성 또는 제대로 문서화되지 않은 코드로 인해 테스트 검사를 해결하기가 더 어려울 수 있습니다. 일반적으로 개발자가 이전 코드베이스 또는 프레임워크 테스트에 익숙하지 않아 문제를 더욱 악화시킬 수 있습니다.

테스트 검사를 개선하는 것은 잘 알려진 모범 사례이지만 많은 팀에서는 이러한 문제를 처리하기 위해 시간과 전문 지식이 많이 필요합니다.

2. 옵션 평가

다음 단계는 1단계에서 확인한 장벽을 해결하기 위한 솔루션을 평가하고 합의하는 것입니다. 이 가이드에서는 GitHub Copilot이 사용자가 파악한 목표에 미칠 수 있는 영향에 대해 중점적으로 살펴보겠습니다. 새로운 도구를 성공적으로 출시하려면 문화와 프로세스도 바뀌어야 한다는 점을 명심하세요.

피드백을 수집하고 성공을 측정하기 위해 파일럿 그룹과 함께 새로운 도구와 프로세스의 평가판을 시험적으로 실행하게 됩니다. 평가판 중에 사용할 학습 리소스 및 메트릭에 대해서는 3. 변경 내용 구현 및 주시해야 할 메트릭 섹션을 참조하세요.

Copilot에 등록

Copilot이 도움을 주는 방식

GitHub Copilot은 단위 테스트 작성 프로세스를 크게 가속화하고 간소화할 수 있습니다. 주변 코드 및 컨텍스트를 이해하면 Copilot에서 테스트 중인 코드의 구조 및 논리와 일치하는 테스트 함수를 제안할 수 있습니다.

Copilot의 기능은 다음과 같은 여러 시나리오에서 유용합니다.

  • 개발자가 새 함수를 작성할 때 Copilot은 해당 테스트 사례를 인라인으로 자동으로 제안할 수 있습니다.
  • 레거시 코드를 리팩터링할 때 Copilot은 회귀를 방지하기 위해 테스트 스캐폴딩을 생성하는 데 도움을 줄 수 있습니다.
  • 테스트되지 않은 모듈의 경우 개발자는 테스트 검사가 없거나 일관되지 않은 경우에도 Copilot에 의미 있는 테스트 사례를 생성하라는 메시지를 표시할 수 있습니다.

Copilot은 단위 테스트를 더 쉽고, 빠르게 만들고 수동 작업을 줄여 테스트 검사의 격차를 초래할 수 있는 마찰을 줄이고, 팀이 품질 우선 사고 방식을 채택하도록 지원합니다.

사용 사례

  • 인라인 테스트 생성: 개발자는 컨텍스트를 전환하지 않고 특정 함수 또는 모듈에 대한 테스트를 생성하도록 Copilot에 요청할 수 있습니다.
  • 더 나은 에지 사례 검사: Copilot에 에지 시나리오(예: null 입력, 빈 목록 또는 잘못된 상태)에 대해 프롬프트하여 개발자는 더 많은 논리 분기를 신속하게 처리할 수 있습니다.
  • 가속 온보딩: 새 팀 구성원은 Copilot을 사용하여 생성된 테스트 사례를 확인함으로써 함수가 어떻게 작동하는지 이해할 수 있습니다.
  • CI/CD 지원: Copilot은 테스트를 빌드 파이프라인에 통합하여 개선된 검사 기능이 품질 게이트를 직접 지원하도록 하는 방법을 제안할 수 있습니다.

문화적 고려 사항

GitHub Copilot을 출시할 때, 목표 달성을 방해할 수 있는 사회적 또는 문화적 요소도 해결해야 합니다.

다음 예는 ESSP의 "Anti-Patterns" 섹션에서 가져온 것입니다.

  • 팀은 수동 테스트에 의존하거나 자동화된 테스트가 부족할 수 있습니다. 이러한 문제는 자동화를 위한 리소스 제약 또는 최신 테스트 도구에 대한 경험 부족으로 인해 발생할 수 있습니다.
  • 팀은 릴리스하기 위해 너무 오래 대기하여 대량의 코드 배치를 한 번에 배포하게 되므로 버그와 회귀를 감지하기가 더 어려워질 수 있습니다. 이러한 상황은 CI/CD 파이프라인 완성도 부족, 엄격한 규정 준수 요구 사항 또는 PR과 배포 간의 긴 검토 주기로 인해 발생할 수 있습니다.

3. 변경 내용 구현

장벽을 극복하기 위한 올바른 접근 방식을 파악하면 파악한 솔루션을 스케일링합니다. 새로운 도구 또는 프로세스를 성공적으로 도입하기 위해서는 도입의 각 부분에 소유권을 할당하고, 목표에 대해 투명하게 소통하고, 효과적인 교육을 제공하고, 성과를 측정하는 것이 중요합니다.

이 섹션에서는 개발자를 위한 예시 시나리오, 모범 사례, 리소스를 제공합니다. 이 섹션을 사용하여 직원들이 Copilot을 목표에 맞춰 사용할 수 있도록 돕는 커뮤니케이션 및 교육 세션을 계획하는 것이 좋습니다.

인라인으로 테스트 생성

  1. VS Code에서 테스트할 함수를 선택하고 Copilot에 다음과 같이 프롬프트합니다. Generate a unit test for this code.
  2. Copilot은 언어 및 구조에 따라 인라인으로 또는 별도의 테스트 파일로 테스트를 생성합니다.
  3. 제안을 검토, 구체화 및 수락합니다.

에지 사례 포괄

  1. 테스트를 작성한 후 Copilot에 다음과 같이 물어봅니다. What are some edge cases I should test for this function?

    또는: Write test cases for when the input is null or empty.

  2. Copilot은 경계 조건을 포괄하는 추가 테스트 사례를 제안합니다.

  3. 테스트를 검토하고 테스트 도구 모음에 통합합니다.

새 코드 이해

  1. 레거시 함수를 선택하고 Copilot에 다음과 같이 요청합니다. Explain what this function does and generate a test to validate it.
  2. Copilot은 함수의 용도를 설명하고 해당 테스트 사례를 제안합니다.
  3. 테스트 사례를 확인하면서 예상 동작을 이해하고 컨텍스트를 신속하게 빌드합니다.

CI/CD에 대한 지원 받기

  1. 테스트 사례를 검토하고 코드베이스에 커밋합니다.
  2. Copilot에 다음과 같이 물어봅니다. Where should I place this test if I want it to run in CI?
  3. 코드베이스의 구조에 따라 Copilot은 테스트 파일을 배치할 위치와 파이프라인 구성을 업데이트하는 방법을 제안합니다.

개발자를 위한 모범 사례

개발자는 다음을 수행해야 합니다.

  • Copilot과 채팅할 때 설명이 포함된 메모나 프롬프트를 사용합니다. 예: Generate unit tests for a function that calculates discounts based on user type and purchase amount.
  • Copilot을 사용하여 논리 검사를 살펴봅니다. 예: What branches or conditions does this function have that should be tested?
  • 다양한 프롬프트 기술을 살펴보고 다양한 AI 모델의 결과를 비교합니다.

개발자는 다음을 수행해서는 안 됩니다.

  • 논리를 검토하지 않고, 생성된 테스트를 수락합니다. 테스트가 실제 요구 사항을 반영하고 실제 입력 및 출력을 처리하는지 확인합니다.
  • 에지 동작 어설션을 건너뜁니다. "정상 경로"만 테스트하는 경우 회귀가 누락될 위험이 있습니다.
  • Copilot을 사용하여 문서화되지 않은 비즈니스 규칙을 추측합니다. 항상 프롬프트 또는 주석을 통해 컨텍스트를 제공합니다.
  • Copilot을 사용자 대신 코드를 검토하는 대상으로 취급합니다. Copilot은 프로세스를 가속화하지만 엔지니어링 판단을 적용해야 합니다.

개발자를 위한 리소스

조사할 메트릭

새로운 도구의 평가판을 평가하고 전체 출시를 통해 일관된 개선 사항을 제공하는지 확인하려면 결과를 모니터링하고 필요한 경우에는 조정해야 합니다. 일반적으로 품질, 속도, 개발자의 행복이라는 핵심 영역을 고려하고 이러한 영역이 어떻게 모여 비즈니스 성과에 기여하는지 살펴보는 것이 좋습니다.

Copilot이 이 특정 목표에 미치는 영향을 평가하기 위해 살펴보기 좋은 몇 가지 지표는 다음과 같습니다.

  • 테스트 검사: Copilot 채택 후 인라인 및 분기 검사의 증가를 추적합니다. 가능하면 CI 파이프라인의 테스트 검사 보고서를 살펴봅니다.
  • 배포 후 버그 비율: 프로덕션 환경에서 보고해야 하는 버그 수가 줄어듭니다.
  • 개발자 신뢰도: 설문 조사 또는 평가서를 사용하여 개발자들이 새 코드를 배포할 때 얼마나 자신감을 느끼는지 평가합니다.
  • 테스트 작성 시간: 단위 테스트를 만드는 데 소요된 시간 단축 결과를 측정합니다.