프론트 엔드 인수 테스트 코드 작성 팁[20221120 TIL]

프로젝트를 진행하면서 너무도 귀찮았던 부분이 인수 테스트였는데 그 이유 중 하나가 인수 테스트 코드를 어떻게 작성할 줄 몰라서였다는 것이다.

아니 인수 테스트를 왜 작성하기가 어려워?

가장 큰 이유는 아마도 기획의 부실이었던 것 같다. 막상 머릿속에 들어있고 참조할 모델이 있다고 안일하게 생각했던 것이 매우 크다. 프런트 엔드의 인수 테스트를 작성하며 사실 부족한 부분이 매우 많았는데 그중 하나가 모호함이었던 것 같다. 실제로 작성을 해보니 내가 그려놓았던 클래스 다이어그램을 참조할 일이 매우 많았고 기획서의 사용자 스토리를 참조하고 보충할 일 또한 매우 많았다.

 

앞 단계를 꼼꼼히 해놓아야 인수 테스트도 나온다.

결국 인수테스트 작성이 귀찮고 번거로웠던 것이 아니라 앞의 단계가 부실하고 내가 기획하려는 도메인 모델이 직접 서비스로 그려내면서 그 그림이 구체화되지 않아서 인수 테스트를 그려 내 가기 너무도 어려웠는데 그냥 귀찮다고 해버렸다.

 

앞의 기획이 잘 되어있으면 일단 써나갈 수 있다. 

프런트엔드의 인수 테스트를 CodeceptJs 를 이용했는데 사실 서비스가 완성 후의 시나리오를 모두 구체화시켜 그려내는 것은 어렵지만 각 시나리오마다 어떤 형태를 취할지 대략적으로는 그려낼 수 있었고 작성해 놓은 기획 시나리오와 클래스 다이어 그램 덕분에 헷갈리는 부분만다 이리저리 헤집지 않고 비교적 수월하게 작성할 수 있었다. 이제서야 나머지 디테일은 코드를 완성해나가며 그려나갈 수 있게 된 것 같다.

 

결론!

1. 기획서를 반드시 내 서비스가 무엇인지 알 수 있도록 꼼꼼히 작성한다. 사용자 스토리와 가치를 반드시 분명히 포함할 것.

2. 클래스 다이어 그램을 작성한다.( 해놓으면 내 입장에서는 너무 좋았다.)

3. 1, 2번이 잘 되지 않는다면 도메인에 대한 이해가 부족하다. 내가 다루는 도메인에 대한 다른 서비스들을 많이 찾아보고 스크랩할 것. 직접 도메인 관련해서 사용경험도 한 번 이상 쌓아볼 것.

4. 1,2,3 이 완벽하면 인수테스트 코드를 기획에 있는 시나리오 별로 작성하며 빠진 것은 없는지 점검하면서 1,2번에 추가하면서 서로 보완하며 작성한다.

 - 반드시 철 지난 서류가 아니라 업데이트를 상시 하는 작업물로 만들 것