본문 바로가기
코딩 아카이브/Golang

TDD와 cleancode로 만들면서 배우면서 Golang backend -5

by SteadyForDeep 2022. 4. 22.
반응형

지난 글에서 굉장히 이상한 부분이 있었다.

2022.04.15 - [코딩 아카이브/Golang] - TDD와 cleancode로 만들면서 배우면서 Golang backend -3

 

TDD와 cleancode로 만들면서 배우면서 Golang backend -3

지난 글 더보기 2022.04.11 - [코딩 아카이브/Golang] - TDD와 cleancode로 만들면서 배우면서 Golang backend -2 TDD와 cleancode로 만들면서 배우면서 Golang backend -2 소스코드는 아래의 깃헙에서 볼 수 있다..

davi06000.tistory.com

위의 글을 보면

Player에 따른 Score를 저장하는 DB가 등장하는데

그냥 Go의 Map을 이용해서 만든 가짜 DB였다.

 

그런데 이 DB를 테스트 코드에서 선언하고 구현 코드에서 불러오는게 맞을까?

아니면 그 반대로 해야할까?

두가지 경우 모두 그냥 내가 임의로 적은 데이터를 불러오고

복사 붙여넣기 수준의 테스트를 진행하는 상황이라

이게 과연 잘 하고 있는건지 의심스러웠다.

 

그래서 현업에 계신 분들이 있는 오픈톡방에 여쭤보니

단위테스트 때는 쿼리를 해석할 수 있는 가짜DB 객체를 만들어서

in-memory test를 진행하고

통합테스트 때는 직접 DB를 도커에 띄워서 작업한다는 답변을 받았다.

 

이때 가짜 DB는 어떤 기준이 되는 것이 아니고

그냥 단순히 DB와 소통이 가능한지 정도의 수준을 판단하는 근거로 사용한다.

 

그래서 이번에는 DB역할을 해주는 페이크 객체를 만들어보고 테스트를 진행하겠다.

우선은 DB역할을 한다는게 뭔지 부터 정의를 해야할 것이다.

DB는 여러가지 경우가 있지만 일단은 간단한 SQL을 이용하는 생각하자.

그러면 아래 순서로 DB를 사용할 수 있을 것이다.

 

1. 테이블을 만든다.

2. 테이블을 조회한다.

3. 테이블에  정보를 업데이트 한다.

4. 테이블에 있는 정보를 불러온다.

5. 테이블을 삭제한다.

 

그러면 위의 세가지 기능을 구현할 수 있는 가짜 DB 객체를 만들어보자.

TDD의 순서에 맞게 우선은 가짜 DB를 작성하지 않고 테스트를 먼저 작성한다.

 

이때 fakeDB 객체를 하나 생성하고 거기서 DB리스트를 받아오는 작업에 대해서 테스트를 작성해보자.

이때 MySQL이라는 struct가 없으므로 생성이 불가능하다는 RED가 뜬다.

 

이렇게 코드를 짜고 나서 테스트를 해보면

슬라이스를 직접 비교하는 기능이 없기 때문에

비교문을 사용할 수 없다고 나온다. 

그러면 테스트에서 초기화 되는 DB를 실제 값과 함께 초기화 해서

값을 비교하도록 하자.

 

이렇게 하면 Green이 된다.

 

이제 빈 객체에서 DB를 생성하는 테스트를 짜보자.

이렇게 하면 위에 함수는 Green을 유지하면서 새로운 Red 케이스가 추가되었다.

 

우선은 이렇게 하드코딩해서 기능이 수행되게 하였다.

결과는 모두 Green이다.

 

리팩토링을 해보자. 저번 글로 작성한 위키를 기준으로 진행한다.

https://github.com/hyun06000/go-backend-with-cleancode-and-tdd/wiki

 

GitHub - hyun06000/go-backend-with-cleancode-and-tdd: Go언어를 이용한 API서버, 거기다 이제 cleancode와 TDD를 곁

Go언어를 이용한 API서버, 거기다 이제 cleancode와 TDD를 곁들인. Contribute to hyun06000/go-backend-with-cleancode-and-tdd development by creating an account on GitHub.

github.com

 

리팩토링을 거친 후의 코드는 이렇게 함수 이름만 보고도

어떤 역할을 수행하는지 신뢰할 수 있는 명확한 코드가 된다.

 

나머지 부분은 코드로 구현후 푸시하고

테스트 코드 말고 구현코드를 어떻게 더 잘 다듬을 수 있을지 고민 해 봐야겠다.

반응형

댓글