어떻게 테스트하는가?

요즘 실용주의 프로그래머나 구글 엔지니어는 이렇게 일한다 등 개발 관련 책을 읽다 보면 '테스트'가 엄청나게 중요하다고 강조한다. 

 

책을 읽다 보면 오 내가 꽤 테스트를 잘 해왔구나 싶으면서도, 부족한 면이 많다는 생각이 들었다. 이에 지금까지 내가 해왔던 테스트 방법을 공유하고, 내게 필요한 개선점을 기록하기 위해 이 글을 남긴다. 일단 테스트 주도 개발 (TDD)나 JUnit, SpringBootTest 이런 내용은 아니다. 기능을 만들며, 일어날 수 있는  다양한 경우의 수를 고려하는 테스트 방식에 대해 이야기하고자 한다. 

 

현재 프로젝트에서 front와 back을 모두 하고 있다. 화면 하나를 맡아서 개발하는 경우가 많았기 때문에, 다양한 경우의 수를 고려해야 했다. 화면을 전반적으로 테스트할 때는 아래와 같은 프로세스를 거쳤다. 대부분의 개발이 끝난 상태라고 가정한다. 

 

 

1. 내가 생각할 수 있는 모든 테스트 케이스를 생각한다. 특히, 예외적인 상황이 뭐가 있을지 머리를 짜내본다. 

2. 표를 그리고, 테스트케이스를 행에다 배치한다.

3. 기능 수행 성공 여부를 컬럼에다가 배치한다. 수행 기능은 아래와 같다. 

• front에서 제대로 데이터가 넘어가는가
• back에서 제대로 데이터를 받는가
• 쿼리가 원하는 조건식 대로 실행되는가
• 제대로 된 데이터가 출력/삽입/수정/삭제되는가
• 응답이 클라이언트까지 제대로 오는가 

4. 케이스를 순차적으로 테스트한다. 

5. 문제가 발생했을 경우, 기능 수행 실패 표시를 하고 나머지를 테스트한다.

6. 전체를 테스트한 뒤, 실패한 조건들의 연관관계를 생각해본다. 

7. 코드를 수정한 뒤, 다시 처음부터 테스트를 이어간다. 

8. 모든 테스트가 통과하면 끝! 

 

예시

조건 (총 14개)	front 데이터	back 데이터	쿼리 실행	쿼리 결과	클라이언트 리턴
배송상태	O	O	O	X	X
계약상태	O	O	O	O	O

 

이 방식의 장점

• 꼼꼼하게 업무를 수행할 수 있다. 
• 다른 사람과 이야기를 나눌 때 보기 편함
• 기록으로 남길 수 있어서 추후 문제가 생겼을 때 보다 파악하기 편함 

이 방식의 단점

• 시간이 엄청나게 오래 걸린다.
• 조건이 많을 경우 경우의 수가 크게 늘어난다. 이 경우 모든 경우의 수를 테스트할 수는 없다. 

스스로 칭찬할 점

• 가능한 경우의 수를 생각해서 저렇게 기록을 해둔다는 게 뿌듯. 6개월 전에 했던 화면 다시 복기하면서 쓰는 건데 참 꼼꼼하고 잘했다 ..^^ 

개선점 

• 지금까지 나는 어느 정도 기능을 만들어놓은 뒤 테스트하는 경우가 많았는데, 실용주의 프로그래머에서 강조한 내용은 '조금씩 개발하고, 조금씩 테스트하기'였다. 
• 프론트는 단위별로 테스트하기가 힘들긴 하지만, BACK 쪽 다룰 때는 조금 개발하고 조금 테스트하고 하는 방식을 생각해봐야겠다. 특히 테스트코드를 많이 활용해보기로.