TotT on philipjkim

TotT: 도메인 객체로 변경에 유연한 코드 작성하기

Thu, 04 Dec 2025 10:12:26 +0900

원문: https://testing.googleblog.com/2024/09/write-change-resilient-code-with-domain.html (Translated by Google Gemini)

제품의 요구사항은 자주 바뀔 수 있지만, 그 근본적인 아이디어는 보통 천천히 변합니다. 이는 흥미로운 통찰로 이어집니다. 만약 우리가 제품의 근본적인 아이디어와 일치하는 코드를 작성한다면, 그 코드는 미래의 제품 변경에도 살아남을 가능성이 더 높습니다.

도메인 객체(Domain objects) 는 우리 코드 안에서 제품의 근본적인 아이디어와 일치하는 구성 요소(클래스나 인터페이스 같은)입니다. 제품 요구사항에 따른 원하는 행동(“텍스트를 흰색으로 설정”)에 맞춰 코드를 작성하는 대신, 우리는 기저에 깔린 아이디어(“텍스트 색상 설정”)에 맞춥니다.

TotT: SMURF - 테스트 피라미드를 넘어서

Wed, 03 Dec 2025 07:56:35 +0900

원문: https://testing.googleblog.com/2023/09/else-nuances.html (Translated by Google Gemini)

테스트 피라미드는 테스트 스위트의 발전을 안내하는 정석적인 경험 법칙(heuristic)입니다. 이는 단순한 메시지를 전달합니다. 통합 테스트보다 더 많은 단위 테스트를 선호하고, 엔드 투 엔드(end-to-end) 테스트보다 더 많은 통합 테스트를 선호하라는 것입니다.

테스트 피라미드는 유용하지만, 테스트 스위트가 커지고 어려운 트레이드오프(trade-off) 상황에 직면했을 때 필요한 세부 정보가 부족합니다. 테스트 스위트를 확장하려면 테스트 피라미드 그 이상이 필요합니다.

SMURF 는 테스트 스위트의 균형을 잡을 때 고려해야 할 트레이드오프들을 기억하기 쉬운 약어입니다:

TotT: Else 문의 미묘한 차이

Wed, 03 Dec 2025 07:49:25 +0900

원문: https://testing.googleblog.com/2023/09/else-nuances.html (Translated by Google Gemini)

함수가 if 문에서 일찍 종료(return)되는 경우, else 절을 사용하는 것과 사용하지 않는 것은 동작상으로는 동일합니다. 하지만 else 절과 가드 절(guard clause, else가 없는 형태)을 적절히 사용하면 코드를 읽는 사람에게 의도를 더 명확하게 전달할 수 있습니다.

함수 구조를 잡는 데 도움이 될 만한 다음 가이드라인들을 고려해 보세요:

특수한 케이스를 미리 처리하기 위해 가드 절(Guard clause)을 사용하세요. 이렇게 하면 나머지 코드는 핵심 로직에 집중할 수 있습니다. 가드 절은 조건을 확인하고 충족되지 않을 경우 빠르게 실패하거나 일찍 반환하여 중첩(nesting)을 줄여줍니다.

TotT: 함수 가독성 향상을 위해 추상화를 활용하세요

Mon, 24 Nov 2025 10:02:42 +0900

원문: https://testing.googleblog.com/2023/09/use-abstraction-to-improve-function.html (Translated by Google Gemini)

아래에 있는 두 가지 createPizza 함수 버전 중 어느 쪽이 이해하기 더 쉬울까요?

A. 추상화 수준이 혼재된 버전 (나쁜 예)

func createPizza(order *Order) *Pizza {
 pizza := &Pizza{Base: order.Size, Sauce: order.Sauce, Cheese: "Mozzarella"}
 if order.kind == "Veg" {
 pizza.Toppings = vegToppings
 } else if order.kind == "Meat" {
 pizza.Toppings = meatToppings
 }

 oven := oven.New()
 if oven.Temp != cookingTemp {
 for (oven.Temp < cookingTemp) {
 time.Sleep(checkOvenInterval)
 oven.Temp = getOvenTemp(oven)
 }
 }

 if !pizza.Baked {
 oven.Insert(pizza)
 time.Sleep(cookTime)
 oven.Remove(pizza)
 pizza.Baked = true
 }

 box := box.New()
 pizza.Boxed = box.PutIn(pizza)
 pizza.Sliced = box.SlicePizza(order.Size)
 pizza.Ready = box.Close()
 return pizza
}

B. 일관된 추상화 수준을 가진 버전 (좋은 예)

func createPizza(order *Order) *Pizza {
 pizza := prepare(order)
 bake(pizza)
 box(pizza)
 return pizza
}

func prepare(order *Order) *Pizza {
 pizza := &Pizza{Base: order.Size, Sauce: order.Sauce, Cheese: "Mozzarella"}
 addToppings(pizza, order.kind)
 return pizza
}

func addToppings(pizza *Pizza, kind string) {
 if kind == "Veg" {
 pizza.Toppings = vegToppings
 } else if kind == "Meat" {
 pizza.Toppings = meatToppings
 }
}

func bake(pizza *Pizza) {
 oven := oven.New()
 heatOven(oven)
 bakePizza(pizza, oven)
}

func heatOven(oven *Oven) { … }

func bakePizza(pizza *Pizza, oven *Oven) { … }

func box(pizza *Pizza) { … }

추상화 수준을 일치시켜야 하는 이유

여러분은 아마 오른쪽(좋은 예)이 더 쉽다고 답했을 것입니다. 하지만 그 이유는 무엇일까요?

TotT: 관심사 분리? 끝!

Mon, 20 Oct 2025 13:17:31 +0900

원문: https://testing.googleblog.com/2020/12/testing-on-toilet-separation-of.html (Translated by Google Gemini)

다음 함수는 SpeedyImg라는 API를 사용하여 바이트 배열을 이미지로 디코딩합니다. 다른 팀이 소유한 API를 참조할 때 어떤 유지보수 문제가 발생할 수 있을까요?

SpeedyImgImage decodeImage(List<SpeedyImgDecoder> decoders, byte[] data) {
 SpeedyImgOptions options = getDefaultConvertOptions();
 for (SpeedyImgDecoder decoder : decoders) {
 SpeedyImgResult decodeResult = decoder.decode(decoder.formatBytes(data));
 SpeedyImgImage image = decodeResult.getImage(options);
 if (validateGoodImage(image)) { return image; }
 }
 throw new RuntimeException();
}

API 호출에 대한 세부 정보가 도메인 로직과 혼합되어 있어 코드를 이해하기 어렵게 만들 수 있습니다. 예를 들어, decoder.formatBytes() 호출은 API에서 필요하지만 바이트가 어떻게 포맷되는지는 도메인 로직과 관련이 없습니다.

TotT: 당신이 소유하지 않은 타입은 목킹(Mock)하지 마세요

Tue, 23 Sep 2025 13:36:30 +0900

원문: https://testing.googleblog.com/2020/07/testing-on-toilet-dont-mock-types-you.html (Translated by Google Gemini)

단위 테스트를 작성할 때, 테스트 대상 코드가 의존하는 타입을 목(mock) 처리하는 것은 일반적인 관행입니다. 하지만, 당신이 소유하지 않은 타입(types you don’t own)을 목 처리하는 것은 거의 항상 피해야 합니다. 여기서 “소유하지 않은 타입"이란 당신의 팀이 작성하거나 관리하지 않는 모든 클래스나 인터페이스를 의미합니다. 여기에는 자바 표준 라이브러리의 URL이나 서드파티 라이브러리의 JSONObject와 같은 타입들이 포함됩니다.

예를 들어, java.net.HttpURLConnection을 직접 목 처리하는 테스트를 생각해 봅시다.

@Test
public void testProcessUrl_connectionFailed() throws Exception {
 HttpURLConnection mockConnection = mock(HttpURLConnection.class);
 when(mockConnection.getResponseCode()).thenThrow(new IOException());

 Processor processor = new Processor();
 assertFalse(processor.processUrl(mockConnection));
}

이 테스트에는 몇 가지 심각한 문제가 있습니다.

TotT: 테스트 데이터를 깔끔하게 만드세요

Mon, 22 Sep 2025 09:29:50 +0900

원문: https://testing.googleblog.com/2018/02/testing-on-toilet-cleanly-create-test.html (Translated by Google Gemini)

테스트를 작성할 때, 우리는 종종 테스트 대상 코드가 소비할 객체들을 만들어야 합니다. 이 객체들은 진짜 객체일 수도 있고, 페이크(fake)나 목(mock) 객체일 수도 있습니다. 이러한 객체들을 생성하는 코드는 빠르게 지저분해지고, 테스트의 가독성을 해치며, 유지보수를 어렵게 만들 수 있습니다.

다음 예제를 살펴보겠습니다.

@Test
public void testWriteSecureMessage() {
 // 테스트를 위한 설정
 Message message = new Message();
 message.setId("42");
 message.setBody("Four score and seven years ago...");
 message.setSignature("1a2b3c4d5e");

 User sender = new User();
 sender.setId("Abc.123");
 sender.setName("Abraham Lincoln");

 // 테스트 실행
 writer.writeSecureMessage(message, sender);

 // 상태 검증
 assertEquals("Sent secure message with signature 1a2b3c4d5e", logger.getInfo());
}

이 테스트에서 객체 생성은 꽤 장황합니다. 테스트의 핵심 로직을 이해하기 어렵게 만들고, 테스트가 실제로 무엇을 검증하려는지 불분명하게 만듭니다.

TotT: 상태를 변경하는 메서드 호출만 검증하세요

Fri, 19 Sep 2025 15:26:56 +0900

원문: https://testing.googleblog.com/2017/01/testing-on-toilet-keep-cause-and-effect.html (Translated by Google Gemini)

이 테스트에서 어떤 라인을 안전하게 제거할 수 있을까요?

@Test
public void addPermissionToDatabase() {
 new UserAuthorizer(mockUserService, mockPermissionDb).grantPermission(USER, READ_ACCESS);

 // 이 메서드 중 하나라도 호출되지 않으면 테스트는 실패합니다.
 verify(mockUserService).isUserActive(USER);
 verify(mockPermissionDb).getPermissions(USER);
 verify(mockPermissionDb).isValidPermission(READ_ACCESS);
 verify(mockPermissionDb).addPermission(USER, READ_ACCESS);
}

정답은 상태를 변경하지 않는 메서드를 검증하는 호출들을 제거할 수 있다는 것입니다.

다른 객체에 대한 메서드 호출은 다음 두 가지 범주 중 하나에 속합니다.

상태 변경(State-changing): 부작용(side effects)이 있고 테스트 대상 코드 외부의 세상을 바꾸는 메서드. 예: sendEmail(), saveRecord(), logAccess().
비-상태 변경(Non-state-changing): 테스트 대상 코드 외부 세상에 대한 정보를 반환하고 아무것도 수정하지 않는 메서드. 예: getUser(), findResults(), readFile().

일반적으로 상태를 변경하지 않는 메서드가 호출되었는지 검증하는 것은 피해야 합니다.

TotT: 중첩 줄이기, 복잡도 낮추기

Wed, 17 Sep 2025 09:49:08 +0900

원문: https://testing.googleblog.com/2017/06/code-health-reduce-nesting-reduce.html (Translated by Google Gemini)

과도하게 중첩된 코드는 가독성을 해치고 오류를 발생시키기 쉽습니다. 아래 두 버전의 코드에서 버그를 찾아보세요.

과도하게 중첩된 코드:

response = server.Call(request)
 
if response.GetStatus() == RPC.OK:
 if response.GetAuthorizedUser():
 if response.GetEnc() == 'utf-8':
 if response.GetRows():
 vals = [ParseRow(r) for r in 
 response.GetRows()]
 avg = sum(vals) / len(vals)
 return avg, vals
 else:
 raise EmptyError()
 else:
 raise AuthError('unauthorized')
 else:
 raise ValueError('wrong encoding')
else:
 raise RpcError(response.GetStatus())

중첩이 적은 코드:

response = server.Call(request)
 
if response.GetStatus() != RPC.OK:
 raise RpcError(response.GetStatus())

if not response.GetAuthorizedUser():
 raise ValueError('wrong encoding')

if response.GetEnc() != 'utf-8':
 raise AuthError('unauthorized')
 
if not response.GetRows():
 raise EmptyError()

vals = [ParseRow(r) for r in 
 response.GetRows()]
avg = sum(vals) / len(vals)
return avg, vals

정답: “wrong encoding"과 “unauthorized” 에러가 서로 바뀌었습니다. 이 버그는 리팩터링된 버전에서 더 쉽게 발견할 수 있는데, 그 이유는 검사가 에러를 처리하는 부분 바로 옆에서 일어나기 때문입니다.

TotT: 원인과 결과를 명확하게 유지하세요

Fri, 12 Sep 2025 12:33:09 +0900

원문: https://testing.googleblog.com/2017/01/testing-on-toilet-keep-cause-and-effect.html (Translated by Google Gemini)

이 테스트가 올바른지 판단할 수 있나요?

@Test
public void testIncrement_existingKey() {
 assertEquals(9, tally.get("key1"));
}

tally 객체가 어떻게 설정되었는지 보지 않고는 알아내는 것이 불가능합니다.

private final Tally tally = new Tally();
@Before
public void setUp() {
 tally.increment("key1", 8);
 tally.increment("key2", 100);
 tally.increment("key1", 0);
 tally.increment("key1", 1);
}

// 200줄 떨어져 있음
@Test 
public void testIncrement_existingKey() {
 assertEquals(9, tally.get("key1"));
}

문제는 key1의 값을 수정하는 부분이 검증(assertion)으로부터 200줄 이상 떨어져 있다는 점입니다. 다시 말해, ‘원인’이 ‘결과’로부터 너무 멀리 숨겨져 있습니다.

TotT: 무엇이 좋은 End-to-End 테스트를 만드는가?

Thu, 11 Sep 2025 10:33:09 +0900

원문: https://testing.googleblog.com/2016/09/testing-on-toilet-what-makes-good-end.html (Translated by Google Gemini)

End-to-end(E2E) 테스트는 시스템의 한쪽 끝에서 다른 쪽 끝까지, 그 사이의 모든 것을 블랙박스로 취급하며 전체 시스템을 테스트합니다. E2E 테스트는 시스템 전반에 걸쳐 나타나는 버그를 잡아낼 수 있습니다. 단위 테스트, 통합 테스트와 더불어 E2E 테스트는 균형 잡힌 테스트 식단의 핵심적인 부분이며, 운영 환경과 거의 유사한 상태에서 시스템의 건전성에 대한 확신을 줍니다.

하지만 안타깝게도, E2E 테스트는 단위 테스트나 통합 테스트보다 느리고, 불안정하며(flaky), 유지보수 비용이 더 비쌉니다. E2E 테스트가 필요한지, 만약 그렇다면 어떻게 작성하는 것이 최선일지 신중하게 고려해야 합니다.

TotT: 변경 감지 테스트는 악몽입니다

Thu, 21 Aug 2025 15:09:05 +0900

원문: https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html (Translated by Google Gemini)

당신은 방금 코드의 동작을 수정하지 않고 리팩토링을 마쳤습니다. 그리고 커밋하기 전에 테스트를 실행했는데… 수많은 단위 테스트가 실패합니다. 실패한 테스트들을 고치면서, 당신은 여러 테스트에 동일한 변환 작업을 기계적으로 적용하며 시간을 낭비하고 있다는 느낌을 받습니다. 아마도 당신은 어떤 메서드에 파라미터를 하나 추가했고, 이제 테스트 코드에 있는 100개의 해당 메서드 호출부에 빈 문자열을 전달하도록 업데이트해야 하는 상황일 겁니다.

테스트를 기계적으로 작성한다는 것은 어떤 모습일까요? 여기 터무니없지만 명확한 예시가 있습니다:

TotT: 구현 세부사항보다 Public API를 테스트하세요

Wed, 20 Aug 2025 16:29:38 +0900

원문: https://testing.googleblog.com/2015/01/testing-on-toilet-prefer-testing-public.html (Translated by Google Gemini)

아래 클래스는 테스트가 필요할까요?

class UserInfoValidator {
 public void validate(UserInfo info) {
 if (info.getDateOfBirth().isInFuture()) {
 throw new ValidationException();
 }
 }
}

이 클래스의 메서드에는 로직이 포함되어 있으니 테스트하는 것이 좋을 수 있습니다. 하지만 이 클래스를 사용하는 유일한 코드가 아래와 같다면 어떨까요?

public class UserInfoService {
 private UserInfoValidator validator;
 public void save(UserInfo info) {
 validator.validate(info); // 값이 유효하지 않으면 예외를 던짐
 writeToDatabase(info);
 }
}

답은 다음과 같습니다: 아마도 UserInfoValidator는 테스트가 필요 없을 것입니다. 왜냐하면 모든 경로를 UserInfoService를 통해 테스트할 수 있기 때문입니다. 여기서 핵심적인 구분은 **이 클래스가 Public API가 아니라 구현 세부사항(implementation detail)**이라는 점입니다.

TotT: 서술적인 테스트 이름 작성하기

Mon, 11 Aug 2025 12:05:33 +0900

원문: https://testing.googleblog.com/2014/10/testing-on-toilet-writing-descriptive.html (Translated by Google Gemini)

여러분은 테스트 이름을 어떻게 짓나요? 아래 코드 샘플을 한번 보세요. 이 테스트가 무엇을 하는지, 어떤 동작을 검증하는지 즉시 파악할 수 있나요?

public void testLogin() {
 // ...
}

이 테스트는 사용자가 성공적으로 로그인하는 시나리오를 테스트할 수도 있고, 잘못된 비밀번호를 입력했을 때의 시나리오를 테스트할 수도 있습니다. 테스트가 무엇을 하는지 이해하려면 테스트의 본문을 읽어야만 합니다. 이제 아래의 다른 테스트 이름을 보세요.

isUserLockedOut_lockOutUserAfterThreeInvalidLoginAttempts

이제 여러분은 테스트 본문을 읽지 않고도, 단지 테스트 이름만 읽는 것만으로 어떤 동작이 테스트되고 있는지 이해할 수 있어야 합니다.

TotT: 테스트에 로직을 넣지 마세요

Mon, 04 Aug 2025 09:20:41 +0900

원문: https://testing.googleblog.com/2014/07/testing-on-toilet-dont-put-logic-in.html (Translated by Google Gemini)

프로그래밍 언어는 우리에게 많은 표현력을 제공합니다. 연산자와 조건문 같은 개념들은 광범위한 입력을 처리하는 프로그램을 작성할 수 있게 해주는 중요한 도구입니다. 하지만 이러한 유연성은 복잡성 증가라는 대가를 치르게 하여, 우리 프로그램을 이해하기 어렵게 만듭니다.

프로덕션 코드와 달리, 테스트에서는 유연성보다 단순성이 더 중요합니다. 대부분의 단위 테스트는 단일의, 알려진 입력이 단일의, 알려진 출력을 생성하는지 검증합니다. 테스트는 입력과 출력을 계산하는 대신 직접 명시함으로써 복잡성을 피할 수 있습니다. 그렇지 않으면 테스트 자체에 버그가 생기기 쉽습니다.

TotT: 위험 중심 테스트 (Risk-Driven Test)

Tue, 29 Jul 2025 10:35:40 +0900

원문: https://testing.googleblog.com/2014/05/testing-on-toilet-risk-driven-testing.html (Translated by Google Gemini)

우리는 모두 코드를 작성할 때 테스트를 작성하도록 길들여져 있습니다 : 단위, 기능, UI 등 모든 것을 말이죠. 우리는 결국 전문가입니다. 우리 중 많은 사람들은 작은 테스트가 작업을 빠르게 진행하게 하고, 더 큰 테스트가 안전과 마무리에 영감을 주는 것을 좋아합니다. 아니면 단순히 검토 중에 비난을 예상할 수도 있습니다. 우리는 이러한 테스트에 너무 익숙해져서 왜 테스트를 작성하는지 더 이상 질문하지 않는 경우가 많습니다. 이것은 낭비적이고 위험할 수 있습니다.

TotT: 효과적인 테스트

Mon, 28 Jul 2025 10:24:47 +0900

원문: https://testing.googleblog.com/2014/05/testing-on-toilet-effective-testing.html (Translated by Google Gemini)

개별 단위 테스트를 작성하든 제품의 전체 테스트 프로세스를 설계하든, 테스트가 코드의 버그를 얼마나 효과적으로 감지하고 보고하는지 다시 한번 생각해보는 것이 중요합니다. 효과적이려면 모든 테스트가 극대화하려고 노력해야 하는 세 가지 중요한 품질이 있습니다.

충실도 (Fidelity)

테스트 대상 코드가 손상되면 테스트는 실패합니다. 고충실도 테스트는 테스트 대상 코드의 결함에 매우 민감하여 버그가 코드에 침투하는 것을 방지하는 데 도움이 됩니다.

테스트가 코드의 모든 경로를 다루고 예상 상태에 대한 모든 관련 assertions 을 포함하는지 확인하여 충실도를 극대화하십시오.

TotT: 메서드가 아닌 동작을 테스트하라

Fri, 25 Jul 2025 09:17:03 +0900

원문: https://testing.googleblog.com/2014/04/testing-on-toilet-test-behaviors-not.html (Translated by Google Gemini)

메서드를 작성한 후 메서드가 수행하는 모든 작업을 확인하는 테스트를 하나만 작성하기 쉽습니다. 그러나 테스트와 public 메서드가 1:1 관계를 가져야 한다고 생각하는 것은 해로울 수 있습니다. 우리가 정말로 테스트하고 싶은 것은 동작이며, 단일 메서드가 여러 동작을 나타낼 수 있고, 단일 동작이 때로는 여러 메서드에 걸쳐 있을 수도 있습니다.

전체 메서드를 확인하는 나쁜 테스트를 살펴보겠습니다.

@Test
public void testProcessTransaction() {
 User user = newUserWithBalance(LOW_BALANCE_THRESHOLD.plus(dollars(2)));
 transactionProcessor.processTransaction(
 user,
 new Transaction("Pile of Beanie Babies", dollars(3)));
 assertContains("You bought a Pile of Beanie Babies", ui.getText());
 assertEquals(1, user.getEmails().size());
 assertEquals("Your balance is low", user.getEmails().get(0).getSubject());
}

구매한 품목의 이름을 표시하고 잔액이 부족하다는 이메일을 보내는 것은 두 가지 별개의 동작이지만, 이 테스트는 동일한 메서드에 의해 트리거된다는 이유만으로 이 두 동작을 함께 살펴봅니다. 이러한 테스트는 추가 동작이 계속 추가됨에 따라 시간이 지남에 따라 매우 커지고 유지 관리가 어려워지는 경우가 많습니다. 결국에는 어떤 입력 부분이 어떤 단정(assertion)에 대한 책임이 있는지 파악하기가 매우 어려워질 것입니다. 테스트 이름이 메서드 이름을 직접적으로 반영한다는 사실 자체가 나쁜 징조입니다.

TotT: 좋은 테스트란 무엇인가?

Thu, 24 Jul 2025 10:02:23 +0900

원문: https://testing.googleblog.com/2014/03/testing-on-toilet-what-makes-good-test.html (Translated by Google Gemini)

단위 테스트는 코드의 정확성을 확인하는 중요한 도구입니다. 그러나 좋은 테스트를 작성하는 것은 단순히 정확성을 확인하는 것 이상입니다. 좋은 단위 테스트는 읽기 쉽고 유지 보수 가능하도록 여러 다른 속성을 보여야 합니다.

좋은 테스트의 한 가지 속성은 명확성입니다. 명확성이란 테스트가 사람들에게 읽기 쉬운 문서 역할을 해야 하며, 테스트 중인 코드를 해당 public API 측면에서 설명해야 함을 의미합니다. 테스트는 구현 세부 사항을 직접 참조해서는 안 됩니다. 클래스의 테스트 이름은 클래스가 하는 모든 것을 말해야 하며, 테스트 자체는 클래스 사용 방법에 대한 예시가 되어야 합니다.

TotT: 구현이 아닌 동작을 테스트하세요

Tue, 22 Jul 2025 16:50:17 +0900

원문: https://testing.googleblog.com/2013/08/testing-on-toilet-test-behavior-not.html (Translated by Google Gemini)

여러분의 신뢰할 수 있는 Calculator 클래스는 많은 행복한 사용자를 보유한 가장 인기 있는 오픈소스 프로젝트 중 하나입니다:

public class Calculator {
 public int add(int a, int b) {
 return a + b; 
 }
}

또한 제대로 작동하는지 확인하는 테스트도 있습니다:

public void testAdd() {
 assertEquals(3, calculator.add(2, 1));
 assertEquals(2, calculator.add(2, 0));
 assertEquals(1, calculator.add(2, -1));
}

그러나 새로운 멋진 라이브러리는 덧셈 연산자 대신 사용하면 코드에서 몇 배의 속도 향상을 약속합니다. 여러분은 이 라이브러리를 사용하기 위해 들뜬 마음으로 코드를 변경합니다:

TotT: 상태 테스트 vs. 상호작용 테스트

Tue, 22 Jul 2025 13:11:07 +0900

원문: https://testing.googleblog.com/2013/03/testing-on-toilet-testing-state-vs.html (Translated by Google Gemini)

단위 테스트가 테스트 중인 코드가 제대로 작동하는지 확인하는 방법은 일반적으로 두 가지가 있습니다: 상태 테스트 또는 상호작용 테스트. 이들의 차이점은 무엇일까요?

상태 테스트는 테스트 중인 코드가 올바른 결과를 반환하는지 확인하는 것을 의미합니다.

public void testSortNumbers() {
 NumberSorter numberSorter = new NumberSorter(quicksort, bubbleSort);
 // 반환된 목록이 정렬되었는지 확인합니다. 어떤 정렬 알고리즘이 사용되었는지는 중요하지 않으며,
 // 올바른 결과가 반환되기만 하면 됩니다.
 assertEquals(
 new ArrayList(1, 2, 3),
 numberSorter.sortNumbers(new ArrayList(3, 1, 2)));
}

상호작용 테스트는 테스트 중인 코드가 특정 메서드를 올바르게 호출하는지 확인하는 것을 의미합니다.

TotT: GUI 테스팅의 MVP 되기

Tue, 22 Jul 2025 10:49:31 +0900

원문: https://testing.googleblog.com/2009/02/with-all-sport-drug-scandals-of-late.html (Translated by Google Gemini)

최근의 모든 스포츠 약물 스캔들로 인해 요즘 좋은 롤 모델을 찾기가 어렵습니다. 하지만 롤 모델이 도메인 모델(비즈니스 엔티티의 객체 모델)이라면 MVP가 되기 위해 속임수를 쓸 필요가 없습니다. Model-View-Presenter를 사용하세요!

MVP는 MVC(Model-View-Controller)와 매우 유사합니다.

MVC에서는 아래 다이어그램과 같이 프레젠테이션 로직이 Controller와 View에 의해 공유됩니다. View는 일반적으로 가시적인 GUI 프레임워크 구성 요소에서 직접 파생되며, 모델을 관찰하고 사용자에게 시각적으로 보여줍니다. Controller는 사용자 이벤트를 모델 변경으로 변환하는 방법을 결정하는 역할을 합니다. MVP에서는 프레젠테이션 로직이 Presenter라고도 알려진 Supervising Controller에 의해 전적으로 처리됩니다.

TotT: 인터페이스 테스트하기

Mon, 21 Jul 2025 10:01:35 +0900

원문: https://testing.googleblog.com/2008/07/tott-testing-against-interfaces.html (Translated by Google Gemini)

부족함에 대한 지속적인 느낌을 억누르기 위해, 당신은 공학 분야의 진정한 통과 의례인 자신만의 행성 파괴 광선총을 만드는 데 시간을 들였습니다. 축하합니다. 그리고 당신은 매우 자랑스러워했지만, 그 다음 주말에 이워크¹ 해설이 포함된 한정판 스타워즈 3부작을 구매하여 데스스타²가 알데라안³을 파괴하는 것을 보고 잘못된 결정을 내렸다는 것을 깨달았습니다. 당신의 행성 파괴 광선총은 파란색 레이저를 가지고 있지만, 녹색 레이저가 훨씬 더 멋있어 보입니다. 하지만 라디오셱⁴에 가서 기존의 파괴 광선총에 끼울 수 있는 녹색 레이저를 사는 것은 간단한 문제가 아닙니다. 녹색 레이저를 가지려면 처음부터 다른 행성 파괴 광선총을 만들어야 할 것입니다. 두 개의 파괴 광선총을 소유하는 것이 하나보다 이웃들의 질투심을 더 자극할 것이므로 당신에게는 괜찮습니다.

TotT: "Static Cling" 퇴치하기

Thu, 17 Jul 2025 17:03:43 +0900

원문: https://testing.googleblog.com/2008/06/defeat-static-cling.html (Translated by Google Gemini)

당신은 페어 프로그래밍을 하고 있고, 많은 뛰어난 사람들이 그렇듯이 소리 내어 말하고 있습니다. “목을 만들고, 주입하고, 테스트를 다시 실행할 거야. 통과해야 하는데… 젠장!” 당신의 파트너는 예외 "ConnectionFactory not initialized"를 발견합니다. “뭐?” 그녀는 말합니다. “뭔가가 데이터베이스를 사용하고 있어? 젠장, 이건 작은 테스트여야 했는데.”

검사해보니 당신의 클래스가 다른 클래스의 정적 메서드를 호출하고 있다는 것을 발견했습니다. Static Cling¹이 발생한 것입니다! 만약 정적 메서드에 의존하는 코드를 생성하는 데이터 지속성 레이어를 (잘못) 사용하고, 주의를 기울이지 않았다면, 당신의 코드는 다음과 같을 수 있습니다.

TotT: 의지할 수 있는 친구들

Wed, 16 Jul 2025 10:47:04 +0900

원문: https://testing.googleblog.com/2008/06/tott-friends-you-can-depend-on.html (Translated by Google Gemini)

테스트 환경에서 사용하기 너무 어렵거나 느린 것에 의존하는 코드를 테스트하고 싶을 때는, 의존성 대신 테스트 더블을 사용하세요. 더미(Dummy)는 API를 만족시키기 위해 가짜 입력 값을 전달합니다.

Item item = new Item(ITEM_NAME);
ShoppingCart cart = new ShoppingCart();
cart.add(item, QUANTITY);
assertEquals(QUANTITY, cart.getItem(ITEM_NAME));

스텁(Stub) 은 실제 객체를 오버라이드하고 하드코딩된 값을 반환합니다. 스텁만을 사용한 테스트는 상태 기반 테스트입니다. 시스템을 실행한 다음 시스템이 예상된 상태인지 확인합니다.

ItemPricer pricer = new ItemPricer() {
 public BigDecimal getPrice(String name){ return PRICE; }
};
ShoppingCart cart = new ShoppingCart(pricer);
cart.add(dummyItem, QUANTITY);
assertEquals(QUANTITY*PRICE, cart.getCost(ITEM_NAME));

목(Mock) 은 값을 반환할 수 있지만, 메서드가 호출되는 방식에도 신경을 씁니다. (“엄격한 목(strict mocks)” 은 메서드 호출 순서에 신경을 쓰는 반면, “유연한 목(lenient mocks)” 은 그렇지 않습니다.) 목을 사용한 테스트는 상호작용 기반 테스트입니다. 목에 기대값을 설정하고, 목은 실행될 때 기대값을 검증합니다. 이 예시는 JMock을 사용하여 목을 생성합니다(EasyMock, Mockito 도 유사합니다):

TotT: 싱글턴을 피하기 위한 의존성 주입 사용하기

Tue, 15 Jul 2025 14:06:34 +0900

원문: https://testing.googleblog.com/2008/05/tott-using-dependancy-injection-to.html (Translated by Google Gemini)

싱글턴을 사용하는 코드를 테스트하기는 어렵습니다. 일반적으로 테스트하려는 코드는 싱글턴 인스턴스와 강력하게 결합되어 있습니다. 싱글턴 객체가 종종 정적 생성자나 정적 메서드에서 생성되기 때문에 싱글턴 객체의 생성을 제어할 수 없습니다. 결과적으로 싱글턴 인스턴스의 동작을 시뮬레이션할 수도 없습니다.

싱글턴 클래스의 구현 변경이 불가능하지만, 싱글턴 클라이언트는 변경이 가능하다면 간단한 리팩터링으로 테스트를 더 쉽게 만들 수 있습니다. 싱글턴 인스턴스로 Server를 사용하는 메서드가 있다고 가정해 봅시다.

public class Client {
 public int process(Params params) {
 Server server = Server.getInstance();
 Data data = server.retrieveData(params);
 ...
 }
}

Client를 리팩터링하여 의존성 주입을 사용하고 싱글턴 패턴의 사용을 완전히 피할 수 있습니다. 어떤 기능도 잃지 않았고, Server의 싱글턴 인스턴스만 존재해야 한다는 요구 사항도 잃지 않았습니다. 유일한 차이점은 Server 인스턴스를 정적 getInstance 메서드에서 가져오는 대신, Client가 생성자에서 받는다는 것입니다. 클래스를 테스트하기 더 쉽게 만들었습니다!

TotT: 시간은 무작위

Mon, 14 Jul 2025 10:30:17 +0900

원문: https://testing.googleblog.com/2008/04/tott-time-is-random.html (Translated by Google Gemini)

메서드의 입력값을 명확하게 식별할 수 없을 때 어떻게 제대로 테스트할 수 있을까요? 다음 Java 메서드를 살펴보세요.

/** 현재 시간으로부터 다음 분의 시작을 나타내는 Date 객체를 반환합니다. */
public Date nextMinuteFromNow() {
 long nowAsMillis = System.currentTimeMillis();
 Date then = new Date(nowAsMillis + 60000);
 then.setSeconds(0);
 then.setMilliseconds(0);
 return then;
}

이 메서드를 효과적으로 테스트하는 데에는 두 가지 장벽이 있습니다.

코너 케이스¹를 테스트하기 쉽지 않습니다. 시스템 클럭이 입력 조건을 제공하는 데에 좌우됩니다.
nextMinuteFromNow() 가 반환될 때, 시간이 변경됩니다. 이는 테스트가 단언이 아니라 추측이 될 것이며, 재현하기 어려운 저빈도 실패를 생성할 수 있습니다… 불안정성입니다! 예를 들어 클래스 로딩 및 가비지 컬렉션 일시 중지가 이에 영향을 미칠 수 있습니다.

System.currentTimeMillis() 가 무작위 숫자 제공자처럼 보이기 시작하나요? 맞습니다! 현재 시간은 *비결정성 (non-determinism)*의 또 다른 원천입니다. nextMinuteFromNow() 의 결과는 입력으로부터 쉽게 결정될 수 없습니다. 다행히도 이것은 쉽게 해결할 수 있습니다. 현재 시간을 제어할 수 있는 입력 매개변수로 만드세요.

TotT: 너무 많은 테스트

Mon, 14 Jul 2025 10:20:26 +0900

원문: https://testing.googleblog.com/2008/02/in-movie-amadeus-austrian-emperor.html (Translated by Google Gemini)

영화 아마데우스에서 오스트리아 황제는 모차르트의 음악에 “음표가 너무 많다”고 비판합니다. 하나의 기능을 테스트하는 데 “너무 많은” 테스트는 몇 개일까요?

메서드 decide를 고려해 봅시다.

public void decide(int a, int b, int c, int d, int e, int f) {
 if (a > b || c > d || e > f) {
 DoOneThing();
 } else {
 DoAnother();
 } // 공간 제약 때문에 한 글자 변수 이름을 사용했습니다.
} // 더 나은 이름을 사용해야 합니다. 제가 하는 대로 하지 말고, 제가 시키는 대로 하세요. :-)

얼마나 많은 테스트를 작성할 수 있을까요? 각 변수에 대해 int 값의 전체 범위를 실행하려면 2^192개의 테스트가 필요할 것입니다. 이렇게 계속한다면 구골 개수의 테스트를 하게 될 것입니다! 너무 많은 테스트입니다.

TotT: 스트룹 효과

Fri, 11 Jul 2025 10:49:44 +0900

원문: https://testing.googleblog.com/2008/02/tott-stroop-effect.html (Translated by Google Gemini)

아래 두 행동을 얼마나 빨리 할 수 있나요?

…25개 단어를 모두 소리 내어 읽기: 빨강, 초록, 파랑, … (지금 시도해 보세요!)
…25가지 색깔을 모두 소리 내어 말하기: 초록, 노랑, 하양… (지금 시도해 보세요!)

두 번째 작업이 더 많은 시간과 노력을 필요로 했나요? 그렇다면, 여러분은 스트룹 효과를 경험하고 있는 것입니다. 스트룹 효과는 대략적으로 레이블(이 경우 단어)이 내용(색깔)과 같은 영역에 있고 의미가 충돌할 때, 레이블이 내용을 이해하는 능력에 방해가 된다는 것을 의미합니다.

TotT: 스텁이 단위 테스트 속도를 높여줍니다

Thu, 10 Jul 2025 16:01:59 +0900

원문: https://testing.googleblog.com/2007/04/tott-stubs-speed-up-your-unit-tests.html (Translated by Google Gemini)

Michael Feathers는 좋은 단위 테스트의 특징을 “빠르게 실행되고 문제 위치를 파악하는 데 도움이 된다"고 정의합니다. 코드에 데이터베이스 액세스, 다른 서버와의 통신, 시간 의존성 등이 있을 때는 이를 달성하기 어렵습니다.

모듈의 일부 종속성에 커스텀 객체를 대체하여 코드를 철저히 테스트하고, 커버리지를 높이며, 1초 이내에 실행할 수 있습니다. 데이터베이스 오류와 같은 드문 시나리오도 시뮬레이션하여 오류 처리 코드를 테스트할 수도 있습니다.

이러한 “커스텀 객체"를 지칭하는 다양한 용어가 사용됩니다. 용어를 명확히 하기 위해 Gerard Meszaros는 다음 정의를 제공합니다.

TotT: 화장실에서 테스팅 (Testing on the Toilet) 소개

Tue, 08 Jul 2025 10:31:22 +0900

원문: https://testing.googleblog.com/2007/01/introducing-testing-on-toilet.html (Translated by Google Gemini)

업데이트 - 2024년 12월: TotT 의 의미는 화장실에서 테스팅 (Testing on the Toilet) 에서 이제 *화장실에서 기술 (Tech on the Toilet)*로 변경되었습니다. 자세한 내용은 다음 게시물을 읽어보세요: 화장실에서 기술: 한 번의 화장실 휴식으로 소프트웨어 우수성 향상. 아래는 2007년의 원본 게시물입니다.

블로거 커멘트: 앞으로 TotT 시리즈를 시간이 날 때마다 하나씩 번역해서 포스팅할 예정입니다. (이미 먼저 포스팅된 글들도 있습니다.)

저희는 여러분이 더 많은 테스트를 작성하기를 바랍니다. 네, 바로 여러분입니다. 테스트는 코드를 리팩토링해야 할 때나 다른 개발자가 기능을 추가할 때 여러분을 보호하는 안전망이라는 말을 이미 들었을 것입니다. 심지어 테스트가 코드 디자인에 도움이 될 수 있다는 것도 알고 있을 것입니다.

TotT: 더 나은 테스트를 위한 가짜(Fake) 사용하기

Mon, 07 Jul 2025 13:23:12 +0900

원문: https://testing.googleblog.com/2013/06/testing-on-toilet-fake-your-way-to.html (Translated by Google Gemini)

수년간 블로그를 운영한 후, 블로그 플랫폼의 API를 사용해보기로 결정했습니다. 이리저리 사용해보다가 문득 깨닫습니다: 원격 블로그 서버와 통신하지 않고도 코드가 작동하는지 어떻게 알 수 있을까요?

public void deletePostsWithTag(Tag tag) {
 for (Post post : blogService.getAllPosts()) {
 if (post.getTags().contains(tag)) { blogService.deletePost(post.getId()); }
 }
}

가짜(Fakes)가 해결책입니다! 가짜는 실제 구현체처럼 작동하지만, 프로덕션 환경에 적합하지 않은 API의 가벼운 구현체입니다. 블로그 서비스의 경우, 중요한 것은 게시물을 가져오고 삭제하는 기능뿐입니다. 실제 블로그 서비스는 데이터베이스와 여러 프런트엔드 서버가 필요하겠지만, 코드를 테스트하는 데는 그런 것이 필요 없습니다. 필요한 것은 블로그 서비스 API의 어떤 구현체든 상관없습니다. 간단한 인메모리 구현체로 이를 달성할 수 있습니다.

TotT: 목(Mock)을 과도하게 사용하지 마세요

Mon, 07 Jul 2025 10:53:23 +0900

원문: https://testing.googleblog.com/2013/05/testing-on-toilet-dont-overuse-mocks.html (Translated by Google Gemini)

코드를 테스트할 때, 코드의 의존성을 목으로 처리하여 무시하는 것이 쉬워 보일 수 있습니다.

public void testCreditCardIsCharged() {
 paymentProcessor = new PaymentProcessor(mockCreditCardServer);
 when(mockCreditCardServer.isServerAvailable()).thenReturn(true);
 when(mockCreditCardServer.beginTransaction()).thenReturn(mockTransactionManager);
 when(mockTransactionManager.getTransaction()).thenReturn(transaction);
 when(mockCreditCardServer.pay(transaction, creditCard, 500)).thenReturn(mockPayment);
 when(mockPayment.isOverMaxBalance()).thenReturn(false);
 paymentProcessor.processPayment(creditCard, Money.dollars(500));
 verify(mockCreditCardServer).pay(transaction, creditCard, 500);
}

하지만 목을 사용하지 않으면 때로는 더 간단하고 유용한 테스트를 만들 수 있습니다.

public void testCreditCardIsCharged() {
 paymentProcessor = new PaymentProcessor(creditCardServer);
 paymentProcessor.processPayment(creditCard, Money.dollars(500));
 assertEquals(500, creditCardServer.getMostRecentCharge(creditCard));
}

목을 과도하게 사용하면 몇 가지 문제가 발생할 수 있습니다.