Programming

[TEST] 1. 테스트를 시작하게 된 계기

foxlee 2021. 10. 23. 00:19

다음 글 2021.10.24 - [개발 고민들] - [TEST] 2.테스트 코드 작성하기

최근 영어 구동사, 이디엄 검색 앱을 만들면서 반복적으로 발생했던 부분이 있다.

  • 간단하게 말해보자면, 프론트단-서버단 사이 데이터 요청/응답을 더 효율적으로 하기 위해 서버에서 계산하는 로직, 응답으로 보내주는 리소스의 구조 등등이 계속 변경되었다.
  •  구체적인 예를 들면, 프론트에서 서버로 데이터를 요청하고, 이에 해당하는 데이터를 응답으로 보내주는 과정에서 프론트에서 필요하지 않은 데이터는 보내지 않아야 하는데 처음엔 저장된 데이터(구동사 리스트+각 구동사의 정의,예제)가 많이 없어 다 같이 보내다가 데이터가 많아진 이후부터는 바꿔야겠다는 생각이 들었다. 최소한 필요한 정보(구동사 리스트)만 보내고 클라이언트에서 특정 데이터(구동사)를 선택했을때 해당 데이터의 상세한 정보(구동사의 예제, 정의)를 보내줌

위와 같은 수정 후 또 수정

  • 기능 수정/추가 후 테스트를 하나하나씩 직접 하면서 성공하면 넘어가고 실패하면 실패한 부분만 하나씩 수정해야 했기에 시간이 많이 낭비되는 거 같았다. 보통 수정한 부분만 직접 테스트하기에 다른 코드들은 잘 돌아갈거라 희망 하며 넘어간다. (+다른 부분을 다 하나하나 직접 테스트하기 시간이 부족) 문제는 수정한 부분이 다른 코드에 영향을 줄 수 있고, 이를 알지 못하고 개발을 진행했을 때 이후 디버깅시 시간이 불필요하게 많이 소요됨
    • 기능 수정/추가시마다 테스트를 해야하고, 상황에 따라 일부/전체 테스트가 필요하다
  • 처음에는 내가 설계를 잘해서 한번에 코딩을 했어야 했는데... 라는 생각도 했고, 사실 개인 프로젝트의 경우 기획, 디자인을 내가 결정하는 거기 때문에 완벽하지 않거나 기능이 개발을 진행하면서 변경/추가되거나, 디자인이 마음에 안들어서 변경하거나 등의 이유로 자주 변동이 생겼다. 이건 어쩔 수 없다... 그리고 어떤 프로젝트를 진행하든 변경 사항, 추가 사항이 생기는 걸 막을 순 없다. 
    • 기능 변경 추가 시 일단 기능이 잘 돌아가면 리팩토링(의존성을 낮게하고 확장성을 높게 등등)이후 다시 변경 사항이 발생했을때 유연성 있게 대처

 

그래서 내가 하고자 하는 것은

  • 먼저 테스트를 코드 작성 후 기능 개발
  • 테스트 코드를 작성하며 테스트 케이스 확인, 기능의 역할을 확실하게 하고, 해당 기능 중복 확인
  • 기능 개발이 완료되어 테스트를 성공하면 높은 확장성, 낮은 의존성, 네이밍 등을 고려해서 리팩토링을 한다.