IT회사 팀사람들과 스터디 하기 5차, 이펙티브 소프트웨어 테스팅, 사례 중심으로 배우는 실전 소프트웨어 테스트 가이드

---

 

🔥 스터디의 시작

2023년이 반정도 지난 지금, 회사에서 5번째 스터디를 진행했다. 

이번에는 테스트 관련된 스터디로 회사에서 테스트 코드를 많이 작성하기 때문에 스터디 주제로 선정하게 되었다 ㅋㅋ

최근에 테스트 시 사용하는 mock과 stub에 차이에 대해서 팀 사람들과 논의한 적이 있었는데, 사용법은 비슷하지만 차이가 있는 것들이었다. 이번에 공부한 책에서 mock, stub, spy에 대해 나온 챕터가 있기 때문에 자세한 설명은 아래를 참고하길 바란다.

 

지난번 스터디였던 몽고 DB는 회사에서 사용하고 있지 않아서 뭔가 설렁설렁 진행한 감이 없지 않아 있었는데, 이번 주제는 어느 정도 업무와 관련이 있다 보니 좀 더 의미 있는 스터디가 되었던 것 같다.

📕 책 소개

이펙티브 소프트웨어 테스팅

사용한 책은 '이펙티브 소프트웨어 테스팅 - 사례 중심으로 배우는 실전 소프트웨어 테스트 가이드'이다. 테스트 관련 책들이 많지는 않기 때문에 아마 아는 사람이 많을 것 같고, 관련해서 외부 스터디도 나름 활발한 것 같다.

 

목차

1. 효율적이고 체계적인 소프트웨어 테스트

2. 명세 기반 테스트

3. 구조적 테스트와 코드 커버리지

4. 계약 설계

5. 속성 기반 테스트

6. 테스트 더블과 모의 객체

7. 테스트 가능성을 위한 설계

8. 테스트 주도 개발

9. 대규모 테스트 작성

10. 테스트 코드 품질

11. 마무리

 

총 350페이지 정도 되며 1주에 2~3 챕터씩 뽀개기로 했다.

 

📝 어떤 것을 배웠나? (기억나는 내용 위주)

1. 효율적이고 체계적인 소프트웨어 테스트

개인적으로 제일 재미있었던 챕터. ( 역시 챕터 1은 재미있다 ㅋㅋ )

테스트에 대한 기본적인 개념이나 왜 써야하는지에 대해서 재미있는 예시를 통해서 알려준다. 테스트코드를 자주 사용하는 개발자와 그렇지 않은 개발자의 업무 스타일을 비교하면서 테스트 코드의 장점을 설명했다. 

 

2. 명세 기반 테스트

번역이 조금 이상하긴 한데, 테스트도 요구사항 정의를 잘해야 한다는 말을 하고 있다. 또 요구사항 정의를 잘하려면 해당 도메인을 잘 알아야 한다는 말도,, 

 

역시 개발자는 개발만 잘하면 되는게 아니라 업무 도메인도 잘 알아야 한다.

 

 

3. 구조적 코드 테스트와 코드 커버리지

테스트 코드를 작성할 때 케이스를 이것저것 생각하면서 짜게 된다. 짝수일 때? 홀수일 때? 값이 길 때? 널 일 때? 등등 다양한 케이스를 생각하게 되는데, 이 중에서 대표적인 케이스 그룹을 나누고, 해당 그룹을 대표하는 값(경계값)으로 테스트를 작성하게 된다. 예를 들어 5보다 큰 경우와 5 이하일 경우 다르게 동작하는 코드를 테스트하기 위해, 테스트 케이스에 5일 경우와 6일 경우를 추가한다. 여태까지 이렇게 하는 게 그냥 자연스럽게 생각하는 대로 짜는 거였는데, 이것도 나름 전략이 있는 방법이었다.

 

전략이름은 MC/DC(Modified Condition / Decision Coverage)로 아무 조건 없이 테스트 케이스를 많이 하면 테스트 코드가 무분별하게 많아지니, 모든 코드에 대한 코드 커버리지를 만족할 수 있는 핵심 테스트 케이스만 선정하여 테스트 코드를 작성하는 것이다. 사실 당연히 이렇게 해야 한다고 생각만 하고 있었는데, 따로 용어로 정의되어 있다니, 앞으로는 "테스트 어떻게 작성하세요?"라고 물으면 "MC/DC를 적용해서 테스트 코드를 작성합니다."라고 대답하면 되겠다.

 

4. 계약 설계

사전 검수와 사후 검수라는 단어를 처음 봤다. 사전 검수는 특정 클래스에서 들어온 인자값에 대한 valid체크를 하는 것을 말하고, 사후 검수는 return해주는 값에 대한 valid체크를 말한다. 이런 사전 검수, 사후 검수를 잘 짜야 테스트가 편하다는 게 내용이었는데 코드를 짜는 걸 기억해 보면 사전 검수는 많이 적용했는데, 사후 검수를 적용한 적은 거의 없는 것 같다.

 

들어온 값은 class에서 확인하는 게 맞는 것 같은데 return까지 검수해야 하나? 왜냐하면 바로 위에서 내가 짠 코드인데 이게 실패할 수가 있나.? 외부 호출이 있는 경우에는 할 수 도 있을 것 같은데, 외부 호출할 때 호출하는 외부 클래스에서는 사전 검수를 하니까 내가 안 해도 되지 않나?라는 꼬리를 무는 질문에 팀원들과 얘기해 봤더니 다들 사후 검수는 갸우뚱한 것 같다. 글쓴이가 좀 과한 듯...

 

6. 테스트 더블과 모의 객체

dummy, fake, stub, mock, spy와 같이 테스트에 사용하는 비슷비슷한 것들이지만 쓰임세가 다 다르다.

- dummy: 테스트에 사용하지 않는 정보

- fake: 실제와 동일한 동작을 하는 다른 객체

- stub: 실제 호출 시 미리 정의해 둔 데이터를 응답하도록 하는 것.

- mock: stub + 호출 행위 자체를 검증

- spy: 실체 호출 행위를 기록하는 것

 

대충 책에는 이렇게 쓰여있는데, 구분해서 사용하지 않아서 그런지,, 느낌만 가져가는 걸로.. ㅋㅋ

 

10. 테스트 코드 품질

테스트 코드 작성할 때 유의점을 모아놨다. 이 챕터의 내용을 요약하면

테스트는 빠르고, 응집력 있고, 독립적이고, 존재 이유가 있어야 하고, 반복가능해야 하고, 안정적이어야 하며, 탄탄해야 하고, 행위가 변경될 경우 깨져야 하고, 명확한 이유로 실패해야 하고, 작성하기 쉬워야 하고, 읽기도 쉬워야 한다. + 유지보수도 쉬워야 한다.

 

 

🙌 스터디 후기

한 때 TDD가 엄청 유행이었다. 너도 나도 TDD를 외치던 시절이었는데, 그때도 나는 TDD에 대해 부정적이었던 것 같다. 이 책을 읽으면서도 역시 TDD는 개발 방법 중에 하나일 뿐이지 MUST는 아니라는 생각이 든다.

 

책에서 보면 TDD의 목적은 테스트가 아니다. 코드의 품질을 높이는 것이 목표다. 테스트를 짜면서 내 코드의 퀄리티를 높이는 것이 TDD의 목적이다. 하지만 코드의 품질을 높이는 방법이 TDD만 있는 것이 아니다. 숙련된 개발자는 테스트코드를 짜지 않아도 에러가 발생할 엣지 케이스나 비즈니스 요건등을 확실히 파악하여 정확한 코드를 짤 수 있다. 사람의 말을 듣고 잘 기억하는 사람이 있는 반면, 메모하면서 기억하는 사람이 있듯이, 바로 코드를 개발해도 잘하는 사람이 있고 테스트코드를 짜면서 개발해야 잘하는 사람이 있다. 이런 건 방법일 뿐이지 목적이 아니다. 따라서 TDD를 하고 안 하고는 개인의 선택인 것 같다. 

 

나는 테스트 코드를 짜는 것은 찬성하지만, TDD는 개인의 취향이라고 생각한다. 내가 해야 한다고 해서 남한테 권하지 말고, 남이 한다고 해서 내가 하지는 말자.

 

팀 사람들 의견도 대~충 비슷했다.