What Do Contribution Guidelines Say About Software Testing?

오픈 소스 소프트웨어 프로젝트를 거대하고 북적이는 커뮤니티 주방이라고 상상해 보세요. 누구나 안으로 걸어 들어와 칼을 집어 들고 채소를 썰며(코드 작성) 더 나은 요리를 만드는 데 도움을 줄 수 있습니다. 하지만 주방이 원활하게 운영되도록, 헤드 셰프(프로젝트 관리자)들은 조리대 위에 **규칙서(Rulebook)**를 남겨둡니다. 이 규칙서는 새로운 조력자들에게 손을 어떻게 씻어야 하는지, 재료는 어디에 있는지, 그리고 자신이 썬 채소가 수프를 망치지 않고 어떻게 제출되어야 하는지를 알려줍니다.

이 논문은 연구팀이 이 유명한 200개의 커뮤니티 주방(구체적으로는 Python과 JavaScript 언어를 사용하는 곳들)에 들어가서 그들의 규칙서를 읽고, **테스트(testing)**에 대해 실제로 무엇을 말하고 있는지 살펴본 결과입니다.

요리의 세계에서 "테스트"는 음식을 내놓기 전에 맛을 보아 비누 맛이 나지는 않는지 확인하는 것과 같습니다. 연구진은 알고 싶었습니다. 규칙서가 실제로 새로운 조력자들에게 음식을 맛보는 법을 가르쳐 주는가, 아니면 그냥 모두가 그 방법을 알고 있다고 가정하는가?

연구 결과는 다음과 같으며, 이해하기 쉽게 정리했습니다.

1. 대부분의 주방에는 "맛보기" 섹션이 있습니다 (하지만 전부는 아닙니다)

연구진은 **78%**의 주방이 맛보기(테스트)를 위한 특정 섹션을 규칙서에 갖추고 있다는 것을 발견했습니다.

• 그 위치는 어디인가요? 대부분의 경우(58%), 이는 문자 그대로 "CONTRIBUTING"이라는 이름의 파일(주요 지침서)에 있습니다. 때로는 별도의 화려한 브로슈어(외부 문서)에 있기도 하며, 드물게는 메인 메뉴판(README)에 적혀 있기도 합니다.
• 공백: 약 22%의 주방은 맛보기에 대한 지침이 전혀 없었습니다. 만약 당신이 그 주방에 들어간다면, 음식의 맛이 좋은지 어떻게 확인할지 스스로 추측해야 할 것입니다.

2. "방법"의 불균형: 실행하기 vs 작성하기

규칙서가 맛보기에 대해 이야기할 때, 그들은 한 가지는 매우 잘했지만 다른 하나는 서툴렀습니다.

• "실행하는 방법" (83.5%): 대부분의 규칙서는 "전체 솥의 맛을 보는 마법 주문(명령어)은 이것이다"라고 명확하게 말합니다. 이는 마치 "맛을 확인하려면 이 버튼을 누르세요"라고 말하는 것과 같습니다.
• "작성하는 방법" (37%): 새로운 맛 테스트를 실제로 어떻게 만드는지에 대해 설명하는 규칙서는 훨씬 적었습니다. 이는 "버튼을 누르세요"라고는 말하지만, 어떻게 새로운 숟가락을 만들거나 무엇이 "나쁜" 맛인지 어떻게 알 수 있는지는 가르쳐주지 않는 것과 같습니다.
• 결과: 조력자들은 기존의 음식을 확인하는 법은 알지만, 자신이 추가한 새로운 재료에 대한 테스트를 어떻게 직접 만들어야 할지는 종종 추측에 맡겨집니다.

3. "테스트 피라미드" 문제

소프트웨어에는 다양한 수준의 테스트가 있으며, 이는 서로 다른 종류의 맛보기와 같습니다:

• 단위 테스트 (Unit Tests, 71%): 이것은 단일 재료를 맛보는 것과 같습니다 (예: "이 당근은 단맛이 나는가?"). 규칙서는 이에 대해 많이 언급했습니다.
• 통합 테스트 (Integration Tests, 20.5%): 이것은 당근과 양파가 솥 안에서 어떻게 어우러지는지 맛보는 것과 같습니다. 규칙서에서 이 부분은 거의 언급되지 않았습니다.
• 엔드 투 엔드 테스트 (End-to-End Tests, 15.5%): 이것은 최종적으로 완성된 요리를 맛보며 전체적인 조화가 잘 맞는지 확인하는 것과 같습니다. 규칙서에서는 이 부분을 거의 언급하지 않았습니다.

비유: 셰프들은 당근의 맛이 제대로 나는지에는 매우 신경을 쓰지만, 조력자들에게 어떻게 하면 전체 스튜가 타버리지 않게 하거나 맛이 잘 섞이게 할 수 있는지에 대해서는 거의 말해주지 않습니다.

4. 사라진 "비밀 무기"들

연구진은 테스트를 더 쉽고 신뢰할 수 있게 만드는 고급 요리 팁들도 살펴보았습니다:

• 모킹 (Mocking, 9.5%): 때때로 실제 바닷물을 수프에 넣고 맛을 볼 수는 없으므로, 이를 시뮬레이션하기 위해 가짜 소금통을 사용해야 합니다. 이것을 "모킹"이라고 합니다. 10곳 중 1곳의 주방만이 이러한 가짜 도구를 사용하는 방법에 대한 지침을 가지고 있었습니다.
• 커버리지 (Coverage, 25.5%): 이것은 레시피의 얼마나 많은 부분이 실제로 맛보였는지를 보여주는 성적표입니다. 약 4분의 1 정도의 주방만이 조력자들이 목표로 해야 할 점수를 알려주었습니다.
• 베스트 프랙티스 (Best Practices, 9%): "항상 내놓기 전에 맛을 보세요"와 같은 일반적인 팁은 매우 드물었습니다.

결론

이 논문은 대부분의 오픈 소스 프로젝트가 조력자들이 자신의 작업을 테스트하기를 원하고 있지만, 그들이 남겨둔 지침은 불균형하다고 결론짓습니다.

그들은 "테스트를 실행하는 방법"을 말하는 데는 뛰어나지만, 다음과 같은 부분에서는 침묵하곤 합니다:

• 새로운 테스트를 작성하는 법.
• 복잡한 상호작용(통합)을 테스트하는 법.
• 전체 시스템(엔드 투 엔드)을 테스트하는 법.
• 고급 도구(모킹)를 사용하거나 품질 목표(커버리지)를 설정하는 법.

핵째: 만약 당신이 이 주방들의 새로운 조력자라면, "맛보기" 버튼을 누르는 법은 알 수 있겠지만, 당신이 만든 새로운 레시피를 위한 맛보기 테스트를 실제로 어떻게 만드는지, 혹은 당신의 새로운 요리가 전체 식사를 망치지 않도록 어떻게 보장해야 하는지에 대해서는 홀로 해결해야 할 수도 있습니다. 저자들은 프로젝트 리더들이 조력자들이 추측하지 않도록 더 명확하고 완전한 지침을 작성해야 한다고 제안합니다.