본문 바로가기
Study/테스트 주도 개발

[TDD] 스터디 4주차 (25~28장 정리)

by Nahwasa 2023. 1. 20.

스터디 메인 페이지

 

25장. 테스트 주도 개발 패턴

⚈ 그 어떤 소프트웨어 엔지니어도 아무리 작은 변화라도 테스트하지 않고 릴리즈하지는 않는다.

 

⚈ 스트레스를 많이 받음 -> 테스트를 점점 뜸하게 함 -> 에러는 점점 많아짐 -> 에러로 인해 더 많은 스트레스!

  • '테스트'를 '자동화된 테스트'로 치환하자.
  • '내가 이걸 고치면서 뭔가 다른 부분을 망가트리지 않았을까?' 라는 두려움을 지루함으로 바꿔주는 효험이 있음

 

⚈ 격리된 테스트 - 테스트들은 서로 영향이 없어야 한다.

 

⚈ 테스트 목록 - 시작하기 전에 작성해야 할 테스트 목록을 모두 적어둘 것. 

 

⚈ 테스트 우선 - 테스트는 언제 작성하는 것이 좋을까? 테스트 대상이 되는 코드를 작성하기 직전!

 

⚈ 단언 우선 - assert는 언제쯤 쓸까? assert를 먼저 쓰고 시작하자.

  • assert를 먼저 작성하면 작업을 단순하게 만드는 강력한 효과를 볼 수 있다.

 

⚈ 테스트 데이터 - 테스트를 읽을 때 쉽고 따라가기 좋을 만한 데이터를 사용하라.

 


26장. 빨간 막대 패턴

[ 테스트를 언제 어디에 작성할 것인지, 테스트 작성을 언제 멈출지에 대한 내용 ]

 

⚈ 목록에서 다음 테스트를 고를 때 무엇을 기준으로? -> 새로운 무언가를 가르쳐 줄 수 있으며, 구현할 수 있다는 확신이 드는 테스트를 고를 것.

  • '아 이건 할 수 있겠다.' 싶은 뻔하진 않지만 구현할 수 있다는 확신이 있는걸 먼저 고를 것

 

⚈ 어떤 테스트부터 시작? -> 오퍼레이션이 아무 일도 하지 않는 경우를 먼저 테스트

 

⚈ 자동화된 테스트가 팀 내에서 더 널리 쓰이게 하려면 -> 테스트를 이용하여 묻고, 테스트를 이용하여 설명해보자.

 

⚈ 학습 테스트 - 외부에서 만든 소프트웨어를 사용할 때, 그냥 바로 사용하는 대신 API가 우리 예상대로 실행된다는 것을 확인해줄 만한 작은 테스트를 만들어보자.

 

⚈ 회귀 테스트(regression test) - 시스템 장애가 보고될 때 -> 그 장애로 인하여 실패하는 테스트, 그리고 통과할 경우엔 장애가 수정되었다고 볼 수 있는 테스트를 가장 간단하게 작성하라.

 

⚈ 길을 잃은 느낌이 들 땐 -> 코드를 다 지워버리고 처음부터 다시 해보자.

 

⚈ 싸구려 책상, 좋은 의자 - 나머지 시설은 싸구려를 쓸지라도 정말 좋은 의자를 구해라.

-> 실천중이닼ㅋㅋㅋ 5만원도 안되는 책상 + 20만원대 의자!

자취방!

 


27장. 테스팅 패턴

지나치게 큰 테스트 케이스를 어떻게 돌아가도록 할까? -> 원래 테스트 케이스의 깨지는 부분에 해당하는 작은 테스트 케이스를 작성하고 그 작은 테스트 케이스가 실행되도록 하라. 그 후에 다시 원래의 큰 테스트를 추가하라.

 

Mock Object -> 비용이 많이 들거나 복잡한 리소스에 의존하는 객체를 테스트할 때 사용

 

호출되지 않을 것 같은 에러 코드(발생하기 힘든 에러 상황) -> 실제 작업을 수행하는 대신 그냥 예외를 발생시키기만 하는 특수한 객체를 만들어서 이를 호출하자.

 

혼자서 프로그래밍할 때 -> 마지막 테스트가 통과하지 않는 상태로 끝마치는 것이 좋다. 그럼 어느 작업부터 시작할 것인지 명백히 알 수 있다. (책갈피처럼)

 

팀 프로그래밍을 할 때 -> 모든 테스트가 성공한 상태로 끝마치는 것이 좋다.

 


28장. 초록 막대 패턴

[ 테스트를 통과하게 만들기 위해 이 패턴들을 사용하자 ]

 

실패하는 테스트를 만든 후 첫 번째 구현 -> 상수를 반환하게 가짜로 구현하자. 왜 들어낼 걸 알면서도 그걸 해야 하나? 뭔가 돌아가는 걸 가진 게 그렇지 않은 것보다 좋기 때문이다. 

 

plus() 만큼 간단한 연산들 -> 그냥 구현해 버려라.

 

객체 컬렉션(collection)을 다루는 연산 -> 일단은 컬렉션없이 구현하고 그 다음에 컬렉션을 사용하게 한다.

댓글