하나의 API test가 다른 API에 의존적이지 않기 위하여 fixture를 이용함에 있어서의 불편함/의문점
Closed this issue · 4 comments
저의 과제3 개인 repo의 README에 올려놓은 의문점인데 질문이 잘 정리된 것 같지 않아 피드백을 받고 잘 다듬어 issue에 올리려다 혹시 저와 비슷한 의문을 가진 분들이 있을까 싶어 issue로 올려봅니다. 혹시 제가 잘못 이해한 부분이나 놓친 부분 있다면 지적 부탁드립니다.
저의 경우 view 단위의 unit test를 작성하는 것 관련하여 #이슈232번을 참고해 하나의 API를 test할 때 다른 API에 의존하지 않도록 fixture loading을 사용하여 test를 구현하였습니다. 이 과정에서 3가지 부분에서 불편함/의문점을 느꼈는데 그에 관해 혹시 좋은 해결 방법을 있나 싶어서 질문을 드립니다.
하나의 API test가 다른 API에 의존적이지 않기 위하여 fixture를 이용함에 있어서의 불편함/의문점 (#이슈232번 관련)
- DB에 query를 날려 object를 생성하는 방식의 번거로움(fixture를 사용한 이유)
setUp()에서 DB에 create query를 날려 객체를 만드는 방식은 relate되는 객체를 모두 만들어야 한다는 문제가 크게 느껴져 사용하지 않았습니다. 예를 들어, User를 만들 때 related 되는 ParticipantProfile 혹은 InstructorProfile, Token 객체도 손수 만들어주어야 하는 것 같은 상황이 너무 번거로울 것 같아 fixture를 이용하는 방식을 선택하였습니다.
- fixture를 만드는 과정에서의 다른 API에 대한 의존성
그러나 위에서 말한 번거로움을 피하기 위해 API를 통하여 data를 만든 다음 그 data를 json 파일로 출력하여 fixture를 만들었는데, 이는 또 다시 다른 API에 의존하게 된 것이 아닌가 하는 의문이 있습니다(fixture를 만들기 위하여 다른 API 사용). 결국 엄밀한 view 단위의 unit test를 위해서는 manually하게 relate되는 객체도 전부 query를 날려 출력할 data를 만들어야 하는 것인지 궁금하고, 또 이 경우 실수할 가능성도 높지 않나 우려됩니다(User만 만들고 Token은 만들지 않는 식의 실수).
- fixture data를 수정해야 할 때의 번거로움
또한 fixture를 이용한 방식은 한번 data를 만들고 나면 수정하기 상당히 어렵다는 것을 발견했습니다. DB 내용 자체를 json으로 출력한 파일이기 때문에 새로운 객체를 추가하고자 하면 model에서의 모든 field들을 전부 명시한(foreign key의 경우에는 해당 primary key까지 모두 손수 작성하여 연결시킴) 객체를 추가하며 json 파일을 편집해 왔습니다. DB에 query를 날려 수정하고, dumpdata로 새로운 fixture를 만드는 방식 말고, 만들어진 fixture를 효과적으로 편집할 수 있는 방법이 있나요? 만약 없다면, 다시 첫 번째 질문으로 돌아가게 되는데, 기존 fixture file을 버리고 DB에 query를 날려 object를 생성하여 dumpdata로 출력해야 하는 것이 최선이 되는 건가요?
- model을 수정하는 migration 이후 fixture 수정 방법
그리고 fixture를 이용하면 model이 바뀌어 migration 할 때마다 fixture file에서 해당하는 모든 부분을 바꾸어주거나 기존 fixture file을 버리고 새로 dumpdata해야 하는 번거로움이 있는 것 같은데, 이 문제는 어떻게 해결하나요?
질문이 애매한 부분이 있다거나, 제가 fixture loading을 다르게 이해한 부분 있다면 말씀해주세요! 미리 감사드립니다.
-
이런 방식이 번거로워보이지만, 실제로 많이 이렇게 합니다. 최대한 관련 코드를 함수화 시키거나 하면 되지 않을까요. 원래 테스트는 번거로운 게 많긴 합니다. 비슷한 질문이 4번째 세미나 직후 질의응답 시간에도 있었는데, test 관련 util들을 잘 만들어두면 꽤나 괜찮습니다. 예를 들어 create_test_user() 같은 함수를 만들어서, 기본적인 정보와 role 정도를 paramter로 넘기게 하여 매번 관련 row들을 잘 생성해주는 코드를 짜두면 되지 않을까요? 재사용성도 높아지고, 한 번 잘 짜두면 실수의 걱정도 없으니까요.
-
API를 통해 data를 만들고 JSON으로 생성했다는 것은, test 코드 내에서 그렇게 동작하게 했다는 것이 아니라 별도로 그렇게 만드셨다는 이야기이지요? 편의성 높은 방식이고, 그렇게 생성된 데이터가 올바른지 확인했다면 그리 문제가 되진 않을 것 같습니다. 이런 건 정답이 있는 것은 아니고, 아무튼 어떤 방식으로든 생성한 fixture를 확실히 검증하면 되겠지요.
-
'수정'하고 싶은 타이밍이 test 실행 중간인지, 아니면 그냥 본인이 원하실 때인지 질문이 조금 애매하다고 생각되는데요. 전자라면, fixture를 이용하여 로직에 따라 fixture 파일이 매번 수정되도록 코드로 작성해두는 것은 느끼시듯 상당히 현실적이지 못한 방식인 것 같습니다. 그걸 fixture라고 말할 수 있을지도 모르겠고, 그럴 거면 그냥 DB 쓰는 게 맞겠다는 생각이 들구요. 0.과 같은 방식으로 하는 것이 차라리 나을 것 같네요.
-
방법이... 딱히... 정 수동이 힘들면 fixture를 스마트하게 변경하는 또 다른 코드를 짠다??? 근데 migration이 빈번하게 일어날 상황이 예견된다면 애초에 fixture를 안 만들 것 같습니다. 뭔가 어쩌면 관련한 package를 누가 만들어둔 게 있을지도 모르고요.
뭔가 시원하고 만족스러운 답변을 드리지 못하는 것 같지만, fixture에 관한 제가 알고 있는 현실이 그렇습니다...
위에서 얼핏 언급되듯, 엄밀히 따지다보면 여러 측면에서 test를 test하는 test가 필요한 거 아닌가... 같은 식의 고민이 들 수 있는데, ㅋㅋㅋ 좀 재밌지요. 어느 정도 적정선을 잘 찾아야 할 필요는 있을 거 같습니다. 원칙을 지키되 효율적인 방식을 찾으려고 노력하구요.
2번은 test 실행 중간은 아니고 하나의 TestCase에서 새로운 test를 추가해나가는 과정에서 fixture에 만들어놓은 data만으로는 불충분해질 때 어떻게 fixture를 편집할지에 대해 들었던 의문이었습니다! fixture 파일을 여러 개 만들어놓고 함께 load하는 경우도 생각해 보았는데, pk가 겹치지 않도록 fixture 파일을 만드는 것도 복잡한 일인 것 같아 질문을 드리게 되었습니다.
0번 관련 답변 들어보니 DB에 insert하는 방식도 처음 함수 짤 때만 감수하면 이후에는 번거롭지 않을 수 있다는 생각도 드네요. 빠른 답변 감사드립니다!!
네, JSON 자체가 결국 그냥 text일뿐이라, 이를 잘 관리해주는 누군가 만들어둔 package를 찾아보거나 본인이 관련한 코드를 작성하지 않는 이상 별다른 뾰족한 수는 없을 것 같습니다. 여러 방식에 장단점이 있는데, 말씀하신 몇 가지 상황들에 대해서는 0.과 같은 방식이 좋아보입니다.