단위 테스트 삭제해야하는 상황

Author: jojoldu

posts/구름_COMMIT_발표/README.md

@@ -12,45 +12,41 @@
 
 
 ```java
-  public class LogAnalyzerTests
-  {
-       public void Analyze_TooShortFileName_CallsWebService()
-       {
-ManualMockService mockService = new ManualMockService ();
-           LogAnalyzer log = new LogAnalyzer(mockService);
-           string tooShortFileName="abc.ext";
-           log.Analyze(tooShortFileName);
-Assert.AreEqual("Filename too short:abc.ext",
-mockService.LastError);
-       }
-   }
-   public class ManualMockService:IWebService
-   {
-       public string LastError;
-
-       public void LogError(string message)
-       {
-           LastError = message;
-       }
-   }
+public class LogAnalyzerTests {
+    public void Analyze_TooShortFileName_CallsWebService() {
+        ManualMockService mockService = new ManualMockService();
+        LogAnalyzer log = new LogAnalyzer(mockService);
+        string tooShortFileName = "abc.ext";
+
+        log.Analyze(tooShortFileName);
+
+        Assert.AreEqual("Filename too short:abc.ext", mockService.LastError);
+    }
+}
+
+public class ManualMockService : IWebService {
+    public string LastError;
+
+    public void LogError(string message) {
+        LastError = message;
+    }
+}
 ```
 
 ```java
- public void Analyze_TooShortFileName_ErrorLoggedToService()
- {
- MockRepository mocks = new MockRepository();
- IWebService simulatedService =
-  MockRespository.DynamicMock<IWebService>();
-
-  using(mocks.Record())
-  {
-     simulatedService.LogError("bad string");
-}
+public void Analyze_TooShortFileName_ErrorLoggedToService() {
+    MockRepository mocks = new MockRepository();
+    IWebService simulatedService = MockRepository.DynamicMock<IWebService>();
+
+    using (mocks.Record()) {
+        simulatedService.LogError("bad string");
+    }
+
+    LogAnalyzer log = new LogAnalyzer(simulatedService);
+    string tooShortFileName = "abc.ext";
 
-       LogAnalyzer log = new LogAnalyzer(simulatedService);
-      string tooShortFileName="abc.ext";
-      log.Analyze(tooShortFileName);
+    log.Analyze(tooShortFileName);
 
-mocks.VerifyAll();
+    mocks.VerifyAll();
 }
 ```

posts/테스트코드를_수정_삭제_해야하는경우/README.md

@@ -15,3 +15,40 @@
 - 테스트 이름을 바꾸거나 리팩터링할 때
 - 중복 테스트를 제거할 경우
 
+
+
+## 
+
+1. 제품(프로덕션) 코드가 변경되어 테스트 시나리오가 실패하거나 의미가 없어졌을 때
+	•	코드 리팩토링으로 인해 구조가 크게 변경되거나, 클래스·메서드가 사라져 기존 테스트가 무의미해진 경우
+	•	기능 변경(요구사항 수정)으로 인해 기존 테스트 시나리오가 더 이상 맞지 않는 경우
+
+이처럼 테스트 자체가 “옛날 이야기”가 되어버리면, 해당 테스트는 수정 혹은 삭제가 필요한다.
+	•	수정: 변경된 로직에 맞추어 테스트 시나리오를 새롭게 잡아야 한다.
+	•	삭제: 기능 자체가 없어지거나 요구사항과 동떨어져서 완전히 무의미해졌다면 미련을 두지 않고 정리하는 편이 좋다.
+
+2. 중복 테스트로 인해 유지보수 효율이 떨어질 때
+	•	동일하거나 매우 흡사한 시나리오를 여러 테스트가 중복해서 다루고 있는 경우
+	•	여러 레벨(Unit, Integration, E2E 등)에서 불필요하게 같은 로직을 과도하게 검증하는 경우
+
+테스트 중복이 심해지면, 수정해야 할 때 여러 곳을 손봐야 하므로 유지보수성이 떨어진다.
+	•	테스트 목적 구분: 단위 테스트, 통합 테스트, E2E 테스트 등 각 수준별로 무엇을 검증해야 하는지 명확히 구분합시다.
+	•	중복 제거: 여러 테스트가 같은 목적을 갖고 있다면 하나로 통합하거나, 꼭 필요치 않다면 삭제하는 것이 좋다.
+
+
+3. 테스트가 지나치게 내부 구현에 의존적일 때
+	•	테스트가 변수명, private 메서드 로직 등 사소한 구현 변경에도 실패하는 경우
+	•	Mock, Stub, Spy 등과 결합이 너무 강해서, 구현 세부사항이 조금만 달라져도 테스트를 대대적으로 고쳐야 하는 경우
+
+테스트는 “구현”이 아니라 “동작(기능)”을 검증해야 한다.
+	•	구현 변경이 잦을 수 있다는 점을 고려해, 테스트가 너무 내부 로직에 밀접하지 않도록 설계한다.
+	•	코드 구조를 바꾸거나, 테스트 자체를 간소화/추상화하는 방향으로 리팩토링이 필요한다.
+	•	문제 해결이 어렵다면, 차라리 테스트를 새로 작성해서 “의도”를 명확히 담는 편이 더 효율적일 수 있다.
+
+4. 유지보수, 가독성이 극도로 떨어져 재작성하는 편이 나은 경우
+	•	테스트 코드 자체가 스파게티처럼 꼬여, 이해가 어려운 상태인 경우
+	•	함수명, 시나리오 명세 등 설명이 전혀 없어 “무엇을 테스트하는지” 알기 어려운 경우
+
+테스트를 수정하는 것보다 아예 새로 작성하는 것이 더 효율적일 수 있다.
+	•	다른 팀원들이나 신입 개발자도 한눈에 이해할 수 있는 테스트가 이상적입니다.
+	•	Naming, 주석, 시나리오 설명을 충분히 작성해주면 향후 유지보수에 큰 도움이 됩니다.