2018. 11. 03 'FEConf 2018' 발표자료입니다.
---
처음으로 프론트엔드 프로젝트에 (유닛)테스트코드를 작성해보며 느낀 경험을 공유합니다. 어떤 관점으로 접근 했는지부터, 테스트코드 작성을 하며 만난 고민과 해결책은 어떤 방식으로 풀어 냈는지 코드와 함께 다뤄보려 합니다. 저는 테스트 숙련자가 아니지만, 저와 비슷한 위치에서 테스트에 입문하시려는 분들께 어떻게 테스트에 입문하고 코드를 작성했는지에 대해서 구체적인 경험을 공유하는 것도 의미있을 거라 생각했습니다. 제가 드릴 얘기들이 정답이 아닐 수 있지만, 더 좋은 방향을 고민하면서 같이 생각해볼 수 있다면 좋겠습니다.
23. 작은테스트경험
• 테스트 작성의 감이 잡힘
• given, when, then을 나누어 작성하는 감
• 테스트코드 작성을 위한 도구들이 익숙해짐
• 파생되는 생각
• 구현코드의 내부로직을 보지 않고도 속성/메서드명으로 테스트코드가
잘 읽혀야 하겠네.
• 그래서 개발이 아니라 코드를 작성한다는 표현을 많이 쓰는 구나.
• 규모있는 프로젝트에서는 수많은 테스트케이스를 어떻게 관리할까?
55. 4.추상화수준이다른메서드간테스트는어떻게해야할까?
(O) 최종 전략: 로직의 복잡한 정도로 판단
상위 메서드의 테스트코드에서 하위 메서드의
• 호출여부를 체크 (X)
• 최종결과를 체크 (O)
renderResultList()의 결과 : 결과목록DOM 갯수 = 응답데이터 배열 길이
openResultList()의 결과 : 결과목록Wrapper의 className
56. 4.추상화수준이다른메서드간테스트는어떻게해야할까?
이때 하위메서드의 로직이 복잡하면
하위메서드의 상세한 테스트를 별도 작성
renderResultList()의 결과 : 결과목록DOM 갯수 = 응답데이터 배열 길이
openResultList()의 결과 : 결과목록Wrapper의 className
(O) 최종 전략: 로직의 복잡한 정도로 판단