고민 되던 부분이 많이 풀렸습니다.

• 좋은 코드와 좋은 테스트 코드가 무엇인지 어떻게 코드를 짜야 할지 고민이 많았습니다. 이에 대한 분명한 대답을 강의를 통해 찾았다고 생각합니다. 그런 차원에서 이번 워밍업 클럽과 박우빈 개발자님의 강의 무척 좋았습니다.

Readable Code - 코드의 추상화 수준을 맞춰보자.

• 추상화가 무엇인지 잘 이해할 수 있게 되었습니다. 그리고 그 추상화의 수준이 코드 전체에서 적절한 수준으로 유지되어야 함을 알게되었습니다.

• 예를 들면, 아래와 같은 코드를 작성하곤 했는데 order라는 추상화된 메서드와 getter를 통한 구체적인 비교 방식은 일종의 추상화 수준이 맞지 않은 읽기 좋지 않은 코드가 됩니다.

   

  OrderResult orderResult = orderService.order(req);
  if(something.getStatus() = SUCCESS){
  // ...
  }

   

• 이런 경우 아래와 같이 order의 수준에 맞는 형태의 추상화를 통해 처리하는 것이 좋아 보입니다.

OrderResult orderResult = orderService.order(req);
if(orderResult.isSuccess()){} //  isSuccess로 적절하게 추상화하거나
notifyMessage(orderResult); // 더 추상화하여 주문 이후 비즈니스 로직을 order 수준으로 맞춘다.

• 지금까제 제가 어떻게 코드를 작성했나 생각해보면, 공통 로직이나 복잡한 로직을 적절한 형태로 추출하는 것에 목표를 가졌지 추상화에 대해서 크게 고민하진 않았습니다. 이런 부분을 배울 수 있어서 좋았습니다.

Practical Testing - 테스트는 문서다

• 저는 테스트를 다소 복잡하게 작성했습니다. 예를 들면 테스트를 위한 공통 객체를 만들거나 공통 기능을 수행하는 순수 테스트 용 유틸 메서드를 만들거나, 테스트 그 자체를 추출한 테스트 메서드를 만들어 테스트를 한 적도 있습니다.

  이것이 문제임을 알곤 있었지만 왜 문제인지는 잘 인지하지 못했습니다.

• 테스트의 목적은 테스트 대상이 어떻게 동작하고 어떤 결과를 기대하는지 설명하기 위한 문서입니다. 이를 달성하기 위해서는

  테스트 대상은 반드시 테스트 블록 안에서 정의되고 동작해야 합니다. @BeforeEach나 별도의 메서드로 생성하고 처리하는 것은 테스트에 부수적으로 필요한 것에 한정되어야 합니다.

   

• 돌이켜보면 공통 추출 가능한 중복된 것은 모두 @BeforeEach에 두거나 별도의 메서드를 둬서 처리해왔습니다. 그럼 테스트를 통과할지언정 테스트 코드가 문서로서 해당 로직의 동작 원리를 보여주진 못합니다. 이런 차원으로 고려한다면 테스트 코드를 더 잘 짤 수 있을 거란 생각을 합니다.

혹시 강의를 볼까 말까 고민이라면?

• 좋은 코드와 좋은 테스트 코드가 무엇인지 고민하시는 분이라면 꼭 보는 것 추천합니다~!