카테고리

테스트가 왜 힘든지를 진단하면서 통증을 넷으로 적었다.

느리다
리팩터링하면 깨진다
손이 많이 간다
뭘 테스트해야 할지 모르겠다

내가 느낀 대로 적은 말이다. 그런데 xUnit Test Patterns (Meszaros, 2007) 를 훑어보니 넷이 전부 이름을 갖고 있었다. 쪽수와 원인 목록과 처방까지 붙어서.

내가 적은 통증 그의 이름 등재된 원인
느리다 Slow Tests (253) Asynchronous Test · General Fixture · Slow Component Usage · Too Many Tests
리팩터링하면 깨진다 Fragile Test (239) Behavior / Context / Data / Interface Sensitivity · Fragile Fixture · Overspecified Software · Sensitive Equality
손이 많이 간다 High Test Maintenance Cost (265) Fragile Test · Hard-to-Test Code · Obscure Test
뭘 테스트할지 모른다 Production Bugs (268) Infrequently Run Tests · Lost Test · Missing Unit Test · Neverfail Test · Untested Code · Untested Requirement

정해야 했던 건 이거였다 — 아픈 곳을 뭐라고 부를 것인가.

지금 나는 「깨진다」 한 단어로 일곱 가지를 부르고 있다. 그 일곱 중 둘만 꺼내 보면 문제가 분명해진다.

깨지는 원인 처방
Data Sensitivity — 테스트 데이터가 바뀌어서 깨진다 테스트마다 자기 데이터를 만든다
Overspecified Software — 목이 구현을 너무 못 박아서 깨진다 못 박은 것을 덜어낸다

처방이 정반대인데 부르는 이름이 같다. 그래서 깨질 때마다 원인을 처음부터 다시 찾는다.

먼저: 나에게는 냄새를 맡을 세 번째 사람이 없다

이 제약을 먼저 세워야 한다. 이것이 아래 원칙 3에서 하나를 통째로 지운다.

Meszaros 는 냄새를 세 종류로 나눈다. 가르는 기준이 「누가 알아채는가」다.

여러 해에 걸쳐 우리는 적어도 두 종류의 냄새가 있다는 것을 알게 됐다. 코드 냄새는 코드를 볼 때 알아채야 하는 것이고, 행동 냄새는 테스트가 실행될 때 결과에 영향을 주는 것이다.

(…) 더 최근에 우리는 세 번째 종류를 식별했다 — 보통 프로젝트 매니저나 고객이 알아채는 냄새다. 그들은 테스트 코드를 보지도 않고 테스트를 돌리지도 않는다.

세 번째의 전제가 「PM 이나 고객」이다. 이 프로젝트에는 그 역할이 없다. 코드를 쓰는 것도 나와 에이전트고, 테스트를 돌리는 것도 나와 에이전트다. 코드도 안 보고 테스트도 안 돌리면서 프로젝트를 지켜보는 사람이 없다.

그리고 지금 표준은 전부 PR 시점에 코드를 보고 막는 형태다. 「이 변경이 괜찮은가」는 묻는데 「스위트 전체가 건강한가」를 묻는 자리가 없다.

원칙 1. 테스트가 아프다고 적을 때는 Meszaros 의 이름으로 적는다

표준·이슈·커밋에서 테스트의 통증을 적을 때 내 말로 적지 않는다.

정해야 했던 건 이거였다 — 이름을 어디서 가져올 것인가.

안 A — 내 말을 그대로 쓴다.

이슈: 테스트가 자꾸 깨진다

얻는 것은 바로 읽힌다는 점이다. 번역도 매핑도 필요 없고, 처음 보는 사람도 무슨 말인지 안다.

버린 이유는 「깨진다」가 일곱 가지를 덮는다는 것이다. 위에서 본 Data Sensitivity 와 Overspecified Software 는 처방이 정반대인데 같은 이름으로 불린다. 그러면 이 이슈를 읽은 다음 사람이 원인 후보를 다시 세우는 것부터 시작한다. 같은 진단을 반복해서 하게 만드는 이름이다.

안 B — 내가 이름을 새로 짓는다.

이슈: 픽스처 결합으로 인한 연쇄 실패

얻는 것은 내 맥락에 딱 맞는 이름이 된다는 점이다. 계약표나 게이트처럼 이 저장소에만 있는 것도 이름 안에 넣을 수 있다.

버린 이유는 원인 목록과 처방을 내가 다시 만들어야 한다는 것이다. 이름만 지어 놓으면 이름값을 못 한다 — 이름이 값을 갖는 건 그 뒤에 「그러면 무엇부터 볼 것인가」가 붙어 있을 때다. Meszaros 는 그걸 원인 일곱 개로 이미 적어 놨다. 같은 것을 다시 짓는 데 드는 시간이 이 안의 값이다.

골랐다 — 안 C. Meszaros 의 이름을 그대로 가져온다.

안 A 와 안 B 가 못 주는 것은 이름에 딸려 오는 것이다. 안 A 는 원인 목록이 아예 없고, 안 B 는 내가 만들어야 한다. 안 C 만 이름을 적는 순간 다음에 볼 곳이 정해진다.

「느리다」                        → 다음에 뭘 볼지 안 나온다
「Too Many Tests 로 인한 Slow Tests」 → 칸 수를 세는 것부터 한다

앞엣것은 불평이고 뒤엣것은 고칠 수 있는 것이다.

대신 영어 용어가 한국어 문서에 섞이는 것을 감수한다. 이 대가를 어떻게 다룰지가 원칙 2다.

원칙 2. 이름은 원어로 적고 번역하지 않는다

Fragile Test 를 「깨지기 쉬운 테스트」로 옮기지 않는다.

안 A — 번역한다.

원어 번역
Fragile Test 깨지기 쉬운 테스트
Data Sensitivity 데이터 민감성
Overspecified Software 과잉 명세된 소프트웨어

얻는 것은 한국어 문서가 한국어로 읽힌다는 점이다. 이 블로그의 글은 전부 한국어 평서체인데 거기에 영어가 박히면 문장이 덜컹거린다.

버린 이유는 책으로 돌아가는 길이 끊긴다는 것이다. 두 군데서 끊긴다.

  • Fragile Test 하나만 옮기면 끝이 아니다. 원인 일곱 개도 전부 옮겨야 한다. 안 옮기면 상위 이름은 한국어인데 하위 원인은 영어인 잡탕이 된다
  • 옮기고 나면 책의 색인에서 「과잉 명세된 소프트웨어」를 찾을 수 없다. 매번 머릿속에서 원어로 되돌려야 한다

어휘를 들이는 이유의 절반이 「책의 원인 목록과 처방에 닿는 것」이다. 번역은 그 통로에 관문을 하나 세운다. 이름은 가져오면서 이름이 가리키던 곳으로는 못 가게 되는 셈이라, 안 A 는 이 표준의 목적과 정면으로 부딪힌다.

골랐다 — 원어 그대로.

대신 문장이 읽기 나빠지는 것을 감수한다. 완화는 하나만 둔다 — 한 문서에서 처음 나올 때만 괄호로 뜻을 붙이고, 그 뒤로는 원어만 쓴다.

Fragile Test(리팩터링하면 깨지는 테스트)가 늘고 있다. 원인은 Data
Sensitivity 쪽으로 보인다.

매번 붙이지 않는 이유는 그러면 번역한 것과 같아지기 때문이다. 괄호는 처음 만나는 사람을 위한 것이지 문서의 표기가 아니다.

원칙 3. 냄새는 셋인데 내가 볼 수 있는 것은 둘뿐이다. 그 사실을 적어 둔다

「먼저」에서 세운 제약이 여기서 하나를 지운다.

종류 누가 알아채나 지금 표준에
코드 냄새 테스트 코드를 읽는 사람 있다 — 표준 대부분이 여기
행동 냄새 테스트를 돌리는 사람 부분적으로 — 게이트가 잡는 것만
프로젝트 냄새 코드도 안 보고 테스트도 안 돌리는 사람 없다

프로젝트 냄새는 넷이다 — Buggy Tests (260) · Developers Not Writing Tests (263) · High Test Maintenance Cost (265) · Production Bugs (268).

문제는 진단의 통증 넷 중 하나가 정확히 여기 있다는 것이다. 「손이 많이 간다」가 High Test Maintenance Cost 다. 파일 하나를 열어봐서는 절대 안 보이고, 몇 달이 쌓여야 보인다. 지금 방식으로는 영원히 안 보인다.

정해야 했던 건 이거였다 — 없는 자리를 만들 것인가.

안 A — 프로젝트 냄새를 보는 자리를 만든다. 주기적으로(릴리스마다?) 스위트 전체를 놓고 넷을 점검한다.

얻는 것은 지금 못 보는 것을 보게 된다는 점이다. 값이 작지 않다 — 통증 넷 중 하나가 여기 있으니 진단의 4분의 1이 여기 걸려 있다.

버린 이유는 볼 사람이 없다는 것이다. Meszaros 의 전제가 「PM 이나 고객」인데 그 역할이 없다. 내가 그 자리에 앉으면 코드도 보고 테스트도 돌리는 사람이 되니 세 번째 종류의 정의를 만족하지 못한다. 자리를 만들어도 돌지 않고 문서에만 남는다. 이 저장소는 그런 규칙이 어떻게 되는지 이미 봤다 — 사람이 계속 기억해야만 지켜지는 규칙은 언젠가 깨진다.

골랐다 — 자리는 만들지 않고 이름만 둔다.

프로젝트 냄새 넷의 이름은 쓴다. 통증을 적을 때 「이건 프로젝트 냄새라 지금 볼 자리가 없다」까지 적는다.

안 A 가 못 지켜주는 것은 없는 것을 없다고 적어 두는 것이다. 자리를 만들었다가 안 돌면 「자리는 있는데 아무도 안 본다」가 되고, 그건 자리가 없는 것보다 나쁘다 — 덮여 있다고 착각하기 때문이다.

대신 High Test Maintenance Cost 는 이름만 있고 보는 자리는 여전히 없는 것을 감수한다. 이건 닫은 것이 아니라 열어 둔 것이므로 장부에 적는다.

원칙 4. 냄새를 적을 때 재서 아는 것인지 느껴서 아는 것인지 함께 적는다

원칙 3 이 「누가 알아채는가」로 갈랐다면, 여기는 「기계가 볼 수 있는가」로 가른다. 다른 질문이다 — 코드 냄새 중에도 기계가 못 보는 것이 있다.

이걸 가르기 전에 지금 값을 한 번 쟀다. 어휘를 들이는 이유의 절반이 「같은 통증이 또 왔는지」를 아는 것인데, 비교할 기준값이 없으면 이름만 있고 쓸모가 없다.

기준일 2026-08-24 · origin/dev 52e9108 · 프로덕션 552파일 / 테스트 109파일

이름 상위 냄새 지표 값
Untested Code (271) · Missing Unit Test (271) Production Bugs (268) 무테스트 도메인 health 하나 (16파일)
Lost Test (269) Production Bugs (268) @Disabled · @Ignore 0
Neverfail Test (274) Production Bugs (268) 뮤테이션 생존 칸 못 잼
Slow Tests (253) 최상위 스위트 실행 시간 못 잼
Fragile Test (239) 최상위 깨짐 횟수 기록 자체가 없음
High Test Maintenance Cost (265) 최상위 고치는 데 든 시간 못 잼

결과가 예상과 반대였다.

  • 자동으로 잡히는 냄새는 이미 걱정할 상태가 아니다. @Disabled 가 하나도 없다. 그래서 Meszaros 가 Lost Test 에 붙인 처방 — 「CI 도구를 무시된 테스트 수가 임계값을 넘으면 빌드를 실패시키도록 설정할 수 있다」 — 은 지금 도입할 이유가 없다. 막을 것이 없다
  • 진단에서 실제로 아팠던 셋은 볼 자리가 없다. Slow Tests · Fragile Test · High Test Maintenance Cost 가 그것이고, 이 셋이 통증 1·2·3번이다

「코드도 안 보고 테스트도 안 돌리는 사람이 알아채는 냄새」라는 정의가 그대로 맞았다. 기계가 보는 곳은 멀쩡했고, 기계가 못 보는 곳이 아팠다.

그래서 규칙은 이렇게 선다.

냄새를 적을 때 재서 아는 것인지 느껴서 아는 것인지를 함께 적는다. 재서 아는 것만 게이트가 볼 수 있다.

느껴서 아는 것에 게이트를 걸려고 하면 지표를 억지로 만들게 되고, 그 순간 테스트 층위 선택 표준이 단위 비율 목표를 버린 것과 같은 일이 난다 — 채우려 들면 채워지고 그 순간 뜻이 없어진다.

무테스트 도메인을 셀 때 함정이 하나 있었다. 도메인 폴더로만 세면 셋이 0으로 나오는데, 계약표는 도메인이 아니라 contract/ 에 따로 산다. 보정하면 진짜 무테스트는 health 하나다. 세는 방법이 값을 바꿨으므로, 지표에는 어떻게 셌는지를 같이 적는다.

판단 기준 정리

질문 답 왜
테스트의 통증을 뭐라고 적나 Meszaros 의 이름 이름에 원인 목록과 처방이 딸려 온다
이름을 번역하나 아니다. 원어 그대로 번역하면 책의 색인으로 돌아가는 길이 끊긴다
뜻은 어디에 적나 한 문서에서 처음 나올 때만 괄호로 매번 붙이면 번역한 것과 같아진다
「깨진다」로 적어도 되나 안 된다 일곱 가지를 덮는다. 처방이 정반대인 둘이 같은 이름이 된다
프로젝트 냄새를 보는 자리를 만드나 아니다. 이름만 둔다 볼 사람이 없다. 안 도는 자리는 자리가 없는 것보다 나쁘다
그러면 「손이 많이 간다」는 이름은 있고 보는 자리는 없다 닫은 게 아니라 열어 둔 것이라 장부에 적는다
냄새마다 무엇을 더 적나 재서 아는 것인가 느껴서 아는 것인가 재서 아는 것만 게이트가 볼 수 있다
느껴서 아는 것에 게이트를 거나 아니다 지표를 억지로 만들게 되고 채우려 들면 채워진다
지표를 적을 때 어떻게 셌는지를 같이 적는다 세는 방법이 값을 바꾼다 — 계약표가 도메인 밖에 살아서 0이 세 개 나왔다

이 표준을 정하기까지

시작은 진단의 통증 넷이었다. 느림 · 깨짐 · 손이 많이 감 · 뭘 테스트할지 모름. 반년 가까이 말로 더듬은 것이고, 어디에도 정식으로 적어 둔 적이 없었다.

책을 훑다가 넷이 전부 등재돼 있는 것을 봤다. 하나가 우연히 겹친 게 아니라 넷 다였다. 쪽수와 원인 목록과 처방까지 붙어 있었다. 내가 반년 걸려 더듬은 것이 2007년 책의 색인에 그대로 있었다.

처음엔 어휘만 바꾸면 끝나는 줄 알았다. 「느리다」를 Slow Tests 로 바꿔 부르는 정도의 일로 봤다. 값은 있지만 작은 일이라고 생각했다.

그런데 냄새를 셋으로 나누는 절에서 방향이 꺾였다. 가르는 기준이 「누가 알아채는가」였고, 세 번째가 「코드도 안 보고 테스트도 안 돌리는 사람」이었다. 그 자리를 지금 아무도 안 맡고 있다는 것을 그때 알았다. 어휘 문제인 줄 알았던 것이 빈자리 문제이기도 했다.

기준값을 재보고 예상이 뒤집혔다. 「자동으로 잡히는 것부터 손보면 되겠다」고 생각하며 쟀는데, @Disabled 가 0이었고 무테스트 도메인도 하나뿐이었다. 기계가 보는 곳은 이미 멀쩡했다. 그리고 진단에서 아팠던 셋은 전부 못 재는 쪽에 있었다. 이 실측이 원칙 4를 만들었고, 동시에 이 안건의 논지를 강하게 만들었다 — 아픈 곳과 볼 수 있는 곳이 어긋나 있다.

여기서 자리를 만들지 말지가 갈렸다. 프로젝트 냄새를 보는 자리를 만드는 안이 값은 제일 컸다. 통증 넷 중 하나가 거기 있으니까. 버린 이유는 볼 사람이 없다는 것 하나였는데, 이게 취향이 아니라 정의상의 문제라 물러설 데가 없었다 — 내가 그 자리에 앉는 순간 「코드도 안 보고 테스트도 안 돌리는 사람」이 아니게 된다. 안 도는 자리를 만들면 덮여 있다고 착각하게 되므로, 없는 것을 없다고 적는 쪽을 골랐다.

글을 쓰다가 내가 이름을 틀리게 적고 있는 것을 발견했다. 통증 표에 Untested Requirement(272) 와 Missing Unit Test(271) 를 Slow Tests·Fragile Test 와 나란히 적어 뒀는데, 책의 List of Smells 를 열어 보니 최상위 냄새는 15개뿐이고 그 둘은 거기 없었다. Lost Test(269) 와 Neverfail Test(274) 도 마찬가지였다. 넷 다 Production Bugs(268) 아래의 원인이다. 쪽수는 맞았는데 층이 틀렸다.

이 실수가 원칙 1 을 스스로 증명했다. 원인만 적으면 형제 원인이 안 보인다. Lost Test 만 적어 두면 같은 부모 아래에 Neverfail Test — 돌기는 도는데 무엇을 깨뜨려도 안 죽는 테스트 — 가 있다는 것을 영영 안 보게 된다. 이름에 원인 목록이 딸려 온다는 게 이 표준의 근거인데, 이름을 한 층 잘못 적으면 그 딸려 오는 것이 통째로 안 온다. 어휘를 들이자고 적으면서 정작 이름을 틀리게 쓰고 있었으니, 원어 표기와 층위를 정확히 적는 것이 이 표준의 전부라는 게 여기서 분명해졌다.

마지막으로 원어냐 번역이냐에서 한 번 더 갈렸다. 이 블로그는 전부 한국어 평서체라 영어가 박히는 것이 싫었다. 그런데 옮기려고 보니 Fragile Test 하나가 아니라 원인 일곱 개가 딸려 있었다. 상위만 옮기면 잡탕이 되고 전부 옮기면 책으로 돌아갈 수 없다. 어휘를 들이는 이유의 절반이 책의 처방에 닿는 것인데 번역이 그 통로를 막는다는 걸 알고 나서 원어로 정했다. 문장이 덜컹거리는 것은 감수한다.

정리

  • 테스트의 통증은 Meszaros 의 이름으로 적는다. 「느리다」는 불평이고 「Slow Tests」는 고칠 수 있는 것이다 — 이름에 원인 목록이 딸려 온다
  • 「깨진다」로 적지 않는다. 그 한 단어가 일곱 가지를 덮고, 그중 둘은 처방이 정반대다
  • 이름은 원어로 적는다. 번역하면 원인 일곱 개도 같이 옮겨야 하고, 책의 색인으로 돌아가는 길이 끊긴다
  • 뜻은 한 문서에서 처음 나올 때만 괄호로 붙인다. 매번 붙이면 번역한 것과 같아진다
  • 냄새는 셋인데 볼 수 있는 것은 둘뿐이다. 프로젝트 냄새는 「PM 이나 고객」을 전제하는데 그 역할이 없다
  • 없는 자리를 만들지 않는다. 안 도는 자리는 자리가 없는 것보다 나쁘다 — 덮여 있다고 착각하게 만든다
  • 재서 아는 것과 느껴서 아는 것을 갈라 적는다. 재서 아는 것만 게이트가 볼 수 있다
  • 느껴서 아는 것에 게이트를 걸지 않는다. 지표를 억지로 만들게 되고, 채우려 들면 채워지고 뜻이 없어진다
  • 지표에는 어떻게 셌는지를 같이 적는다. 계약표가 도메인 밖에 살아서 무테스트 도메인이 셋으로 잘못 나왔다

AI 코드 어시스턴트에 바로 적용하기

Claude Code — .claude/skills/test-smell-vocabulary-standard/SKILL.md

---
name: test-smell-vocabulary-standard
description: 테스트가 아프다고 적을 때 쓰는 이름. 이슈·커밋·표준에 테스트의 통증을 적을 때, 테스트가 느리다거나 깨진다거나 손이 많이 간다고 판단했을 때, 테스트 지표를 세어 보고할 때 적용한다.
---

# 테스트 냄새 어휘 표준

테스트의 통증은 `xUnit Test Patterns`(Meszaros, 2007)의 이름으로 적는다. 이름에 원인 목록과 처방이 딸려 오므로, 이름을 적는 순간 다음에 볼 곳이 정해진다.

## 이름으로 적는다

- 테스트의 통증을 내 말로 적지 않는다. **Meszaros 의 이름과 쪽수로 적는다.**
- **「깨진다」로 적지 않는다.** `Fragile Test`(239)의 원인 일곱 중 어느 것인지까지 적는다 — Behavior / Context / Data / Interface Sensitivity · Fragile Fixture · Overspecified Software · Sensitive Equality.
- 원인을 아직 모르면 **모른다고 적는다.** 아무 원인이나 고르지 않는다.

| 통증 | 이름 | 상위 냄새 |
|---|---|---|
| 느리다 | `Slow Tests`(253) | 최상위 |
| 리팩터링하면 깨진다 | `Fragile Test`(239) | 최상위 |
| 손이 많이 간다 | `High Test Maintenance Cost`(265) | 최상위 |
| 뭘 테스트할지 모른다 | `Untested Requirement`(272) · `Untested Code`(271) · `Missing Unit Test`(271) | `Production Bugs`(268) |
| 꺼둔 테스트 | `Lost Test`(269) | `Production Bugs`(268) |
| 초록인데 안 죽는 테스트 | `Neverfail Test`(274) | `Production Bugs`(268) |

- **원인을 최상위 냄새인 것처럼 적지 않는다.** 최상위는 15개뿐이고(`List of Smells`), 나머지는 그 아래 원인이다. 원인만 적으면 형제 원인들이 안 보인다 — `Lost Test` 만 적으면 같은 `Production Bugs` 아래의 `Neverfail Test` 를 안 보게 된다.

## 원어로 적는다

- 이름을 **번역하지 않는다.** `Fragile Test` 를 「깨지기 쉬운 테스트」로 옮기지 않는다.
- 뜻은 **한 문서에서 처음 나올 때만 괄호로** 붙인다. 그 뒤로는 원어만 쓴다.
- 상위 이름만 옮기고 원인을 안 옮기는 잡탕을 만들지 않는다.

## 볼 수 없는 것은 볼 수 없다고 적는다

냄새는 셋이고 가르는 기준은 「누가 알아채는가」다.

| 종류 | 알아채는 사람 | 이 저장소에 |
|---|---|---|
| 코드 냄새 | 테스트 코드를 읽는 사람 | 있다 |
| 행동 냄새 | 테스트를 돌리는 사람 | 게이트가 잡는 것만 |
| 프로젝트 냄새 | 코드도 안 보고 테스트도 안 돌리는 사람 | **없다** |

- 프로젝트 냄새(`Buggy Tests` 260 · `Developers Not Writing Tests` 263 · `High Test Maintenance Cost` 265 · `Production Bugs` 268)를 적을 때는 **「지금 볼 자리가 없다」까지 적는다.**
- **프로젝트 냄새를 보는 주기 점검 자리를 만들지 않는다.** 볼 사람이 없어서 안 돈다. 안 도는 자리는 덮여 있다는 착각을 만든다.

## 재는 것과 느끼는 것을 갈라 적는다

- 냄새를 적을 때 **재서 아는 것인지 느껴서 아는 것인지**를 함께 적는다.
- **재서 아는 것만 게이트에 건다.** 느껴서 아는 것에 게이트를 걸지 않는다 — 지표를 억지로 만들게 되고, 채우려 들면 채워지고 뜻이 없어진다.
- 지표를 보고할 때 **어떻게 셌는지를 같이 적는다.** 세는 방법이 값을 바꾼다.
- 계약 칸을 셀 때 **줄 단위로 세지 않는다.** 포맷터가 enum 상수를 한 줄에 여러 개 붙이므로 토큰으로 센다.
- 도메인별 테스트 유무를 셀 때 **계약표가 도메인 폴더 밖에 산다는 것을 보정한다.** 안 하면 무테스트 도메인이 부풀어 나온다.

GitHub Copilot — .github/instructions/test-smell-vocabulary-standard.instructions.md

---
description: 테스트가 아프다고 적을 때 쓰는 이름
applyTo: "**/*.md"
---

# 테스트 냄새 어휘

- 테스트의 통증을 내 말로 적지 않는다. `xUnit Test Patterns`(Meszaros, 2007)의 이름과 쪽수로 적는다.
- 「깨진다」로 적지 않는다. `Fragile Test`(239)의 원인 일곱 중 어느 것인지까지 적는다.
- 원인을 아직 모르면 모른다고 적는다. 아무 원인이나 고르지 않는다.
- 원인을 최상위 냄새인 것처럼 적지 않는다. 최상위는 `List of Smells` 의 15개뿐이고, `Lost Test`·`Neverfail Test`·`Untested Code`·`Untested Requirement`·`Missing Unit Test` 는 전부 `Production Bugs`(268) 아래의 원인이다.
- 이름을 번역하지 않는다. 뜻은 한 문서에서 처음 나올 때만 괄호로 붙이고, 그 뒤로는 원어만 쓴다.
- 프로젝트 냄새(`Buggy Tests` · `Developers Not Writing Tests` · `High Test Maintenance Cost` · `Production Bugs`)를 적을 때는 「지금 볼 자리가 없다」까지 적는다.
- 프로젝트 냄새를 보는 주기 점검 자리를 만들지 않는다. 볼 사람이 없어서 안 돈다.
- 냄새를 적을 때 재서 아는 것인지 느껴서 아는 것인지 함께 적는다.
- 재서 아는 것만 게이트에 건다. 느껴서 아는 것에 게이트를 걸지 않는다.
- 지표를 보고할 때 어떻게 셌는지를 같이 적는다. 세는 방법이 값을 바꾼다.
자신만의 철학을 만들어가는 중입니다.
최상단으로 이동했습니다!
확대 이미지

댓글남기기

다른 포스트