TIL #22) test code - 의존성 주입하기

Today I Learned

오늘은 과제 1차 제출일이다. 필수구현사항을 다 하지 못하고 낸게 큰 충격.. 

뭔가 정말 열심히 시간을 많이 들였다면 시간내에 다 했을 수도 있을것 같은데, 이상하게 이번 과제는 너무 손 대기가 싫었다.. 그게 결국 잘 모르는거라서, 어려워서 이해하기 싫어서 그랬던 거겠지.

어려운걸 붙잡고있으니까 자신감이 떨어지는 기분이 든다..

그래도 TIL도 결국 오늘 하루 더 알게된것에 대해 쓰는거니까!

다들 이런 기분을 공유하는것 같아 조금은 위로가 됐다. 다들 힘냅시다.. 

실제로 테스트 코드를 잘 아는사람들은 많이 없어서 깊이 파게되면 취업에도 도움이 된다한다.

마음을 다잡고 가보자고 🤯

 

궁금한 것 & 알아낸 것

- mock fucntion 특정 메서드가 몇번 실행됐는지 아는게 뭐가 중요한거임?

=> 여기저기 물어봐도 결국 답을 얻지못했음. 테스트 코드라는게 오류를 최소화 하기 위한거니까 함수 실행횟수도 관념적으로 넣는다 정도로 이해했다. 그리고 지금 나의 수준보다 더 복잡한 코드를 짜다보면 이런게 필요할때도 있을지도..?

1. 동작 검증 (Behavior Verification): 메서드가 특정 횟수로 호출되었는지 확인하여 코드의 동작을 검증할 수 있습니다. 예를 들어, 함수가 정확한 횟수로 호출되지 않았다면 예상한 동작이 이루어지지 않았을 가능성이 있습니다.
2. 효과적인 테스트 케이스 작성: 특정 메서드가 예상한 횟수로 호출되었는지 확인하면 테스트 케이스를 더 효과적으로 작성할 수 있습니다. 예를 들어, 0번, 1번, 여러 번 호출 등 다양한 상황에 대한 테스트를 구성할 수 있습니다.
3. 부작용 및 상태 변경 감시: 특정 메서드 호출 횟수를 추적하면 메서드가 호출됨에 따라 어떤 부작용이 발생하는지 또는 객체의 상태가 어떻게 변경되는지를 감시할 수 있습니다. 이는 코드가 예상대로 상태를 변경하고 유지하는지 확인하는 데 도움이 됩니다.
4. 버그 및 예외 상황 탐지: 특정 메서드가 예상보다 더 자주 또는 덜 자주 호출되는 경우 이는 코드에 버그나 예외 상황이 발생할 수 있음을 나타낼 수 있습니다.
Mock 함수의 호출 횟수를 검증하여 코드의 일관성과 안정성을 확보하면서 효과적인 테스트를 수행할 수 있습니다. 이는 테스트 주도 개발(Test-Driven Development, TDD)이나 단위 테스트, 통합 테스트 등의 소프트웨어 개발 방법론에서 중요한 원칙 중 하나입니다.

- 실제 데이터베이스를 이용할떄는 프리즈마를 불러와서 실제 데이터가 존재해야 테스트를 실행할수있는데,

  mock을 사용하면 없는 데이터를 실제로 있는것처럼 만들어낼수있다?

Mock 데이터를 사용하면 특정 상황을 재현하거나 원하는 데이터를 가짜로 생성해 테스트 가능하다!
이런 방법은 테스트 환경을 격리시켜 테스트를 더 효과적으로 수행할 수 있게 해준다. 
또한, 특별한 상황이나 오류 조건등을 시뮬레이션할 때 유용하게 사용된다.

 

- 의존성 주입하기 너무 귀찮은데(모든 코드에 수정이 필요) 그럼 테스트가 끝나면 의존성 주입해놓은걸 삭제하기 위해서 
  다시 하나하나 수정하는 방법밖에 없는거임???

1. 코드 생성 도구 사용: 일부 코드 생성 도구를 사용하여 의존성 주입 코드를 자동으로 생성할 수 있습니다. 이를 통해 초기 설정 시 코드 수정이 줄어들며, 테스트가 끝나면 다시 원래 코드로 복원할 수 있습니다.
2. AOP(Aspect-Oriented Programming) 활용: AOP를 이용하여 의존성 주입을 추가하는 코드를 측면에 추가할 수 있습니다. 테스트를 위해 필요한 의존성 주입이나 모의 객체는 테스트 전용 AOP 설정을 통해 주입하고, 테스트 이후에는 제거할 수 있습니다.환경 변수 또는 설정 파일 활용: 의존성 주입을 관리하는 설정을 환경 변수나 별도의 설정 파일에 기록해두고, 필요할 때 이를 변경하여 테스트를 진행한 뒤, 테스트 이후에 다시 원래 설정으로 돌릴 수 있습니다.
3. DI 컨테이너 활용: 의존성 주입 컨테이너를 사용하면 객체의 생성과 의존성 주입을 관리할 수 있습니다. 테스트 시에는 모의 객체로 교체하거나 필요한 의존성을 주입한 객체를 사용할 수 있습니다.
4. 컴파일러 디렉티브 활용: 특정 컴파일러 디렉티브를 사용하여 특정 코드 블록이 컴파일되거나 무시되도록 조건부로 코드를 작성할 수 있습니다. 이를 이용하여 테스트용 코드 블록을 추가하고 필요 없어진 경우에는 해당 블록을 무시하도록 할 수 있습니다.
의존성 주입을 도입하면 코드의 유지보수성과 테스트 용이성이 향상되지만, 초기에는 기존 코드를 수정해야 하기 때문에 번거로울 수 있습니다. 그러나 의존성 주입이 가져오는 장점을 고려하면서 작업하는 것이 좋습니다.

---

repository test 코드 작성하기
1. 실제 사용된 프리즈마 함수들에 jest.fn()을 먹여준다.
2. const createdResume = await this.prisma.resumes.create({
   this.prisma => mockPrisma 안에 들어가도록!! 만든다 생각하면 됨
3. 테스트는 기본적으로 임의로 준 값과 실제로 준 값이 최종적으로 같은값인지 확인하는 방식
   함수사용횟수도 정하기

? 임의로 준 값과 전달한 데이터가 같은값인지 비교하는건 왜 하는걸까..
  그니까 무슨 의미인거임??

=> 데이터 일관성을 확인하기 위해 필요하다. 사용자 입력과 기대값의 일치 여부를 검증하기 위해 사용한다.

? mockReturn 값에 띄어쓰기는 꼭 필요한건가? 아니면 그냥 임의로..?

=> 실제로 해보니 띄어쓰기는 중요한 값은 아닌것 같다. 그냥 개발자가 보기 편한대로 작성하면 될듯

---

스탠다드 수업

<의존성 역전 원칙 DIP>
상위수준모듈에 객체가 의존하고있으면
그 하위들은 다 딸려오는게 가능

무조건 상위로 만들어야된다라는.. 작은게 와도 구현이 되어야 좋은코드

---------
<디자인패턴 - 전략패턴>
특정한 작업을 독립적으로 정의하고 캡슐화, 해당 작업을 동적으로 교체할수있도록 하는 패턴

달라지는 부분과, 달라지지않는 부분과 분리(캡슐화) => 인터페이스를 사용
차이점에 대해서 인터페이스로 각각 만들어주기
난다 - 날수있다, 날수없다(인터페이스 - 클래스, 클래스)
운다 - 꽥꽥, 삑삑, 못운다
이런식으로 개별적인 행동을 만든다.