2020.10.15.
어찌어찌 프로젝트가 살아남았고 간단한 Admin 포털을 또 만들 기회가 있었다.
지난번에 이어 이번에도 개발 소감을 요약해본다 (2020.10.15. 기준).
개발환경: win10 좋다
- OS: win10 + wsl + windows terminal
- tool: vim, tmux, nodejs, vue-cli
- framework/lib: vue, vue-router, vuetify, vuex, axios
- runtime: firefox + vue dev-tools
프론트엔드 프레임워크: Vue 좋다
- 컴포넌트
. 통상 웹UI 컴포넌트 하나를 구현하려면 html, css, js 3개 파일이 필요
. Vue는 UI 컴포넌트 하나를 하나의 파일로 정의 (SFC: Single File Component)
. 개발/관리 측면에서 좋았음
- 급격하지 않은 변화
. 개발 진행중에 Vuetify 문서가 버전업됨
. 하지만 변화 폭이 크지 않아서 쉽게 적응할 수 있었음
. Vue 프레임워크 자체도 곧 3.0으로 버전업될 예정. 하지만 Vue 2.0과 크게 다르지 않을 예정
. "변화 폭이 크지 않고, 변화 방향이 합리적"인 것이 프레임워크의 중요한 장점이라 생각함
디버깅툴: Firefox + Vue Dev-tools 좋다
- Vue dev-tools의 vuex 히스토리 기능이 큰 도움 됨
어플리케이션의 상태 정보를 확인해서 해결되는 문제가 (생각보다) 많았음
- vuex의 mutation은 존재 의미를 불신하던 기능 (필요 없다 생각했음)
Vue dev-tools 활용만으로도 vuex mutation의 가치를 느낌
프론트엔드 TDD: 정말 유용한가?
- 백엔드 tool을 개발하면서 TDD의 유용성을 체감함
- 그래서 프론트엔드 개발에도 TDD를 적용하는 것이 도리일 것이라고 생각,
이번 작업에서 프론트엔드 TDD를 시도해봄
- 구현 코드보다 테스트 코드를 먼저 작성하면서 개발 요구사항을 정리해봄
생각을 정리한다는 측면에서 나름 의미는 있었지만,
- 프론트엔드 테스트 코드는 구현 코드와 밀결합될 수 밖에 없음을 느낌
그리고 프론트엔드의 문제점은 테스트 코드보다 눈과 손으로 먼저 체크하게 됨을 느낌
- 테스트 코드를 작성하는 번거로움 대비 실익을 느낄 수 없었음
- 단기간(3달) 동안 거의 혼자 하는 개발이어서 그랬을지도 모름. 베스트프랙틱스에 대한 조언을 구함
(이상)
2021-04-25.
HTML 태그의 data- 속성을 이용해서 실제 구현 코드와 테스트 코드의 의존성을 분리할 수 있다는 조언을 들었다.
예를 들어 화면에 표시되는 메시지 문자열을 검증하는 테스트 코드를 만들 경우, 특별한 data- 속성 (예를 들어 data-test-id="message")을 가진 HTML 요소를 찾아 그 문자열을 검증하면 된다. 이렇게 하면 개발자가 해당 문자열을 표현하기 위해 어떤 HTML 태그를 쓰는지, 어떤 id를 쓰는지 같은 세세한 구현 디테일과 분리된 테스트 코드를 작성할 수 있다. 그러면 차후 HTML 구조가 바뀌거나 엘리먼트 id가 바뀌어도 테스트 코드는 변경 없이 유지할 수 있다.
2022-03-14.
프론트엔드 TDD에 관한 좋은 책을 발견해서 많이 배웠다.
Testing Vue.js Applications
-- Edd Yerburgh 지음
-- Manning 펴냄
-- https://www.manning.com/books/testing-vue-js-applications
Testing Vue.js Applications
Testing Vue.js Applications</i> is a comprehensive guide to testing Vue components, methods, events, and output. Author Edd Yerburgh, creator of the Vue testing utility, explains the best testing practices in Vue along with an evergreen methodology that ap
www.manning.com
책 구석구석에서 Vue.js와 TDD에 대한 저자의 풍부한 경험을 배울 수 있었다.
무엇보다 TDD에 관해 "하면 안되는 것들" 을 분명히 일러주는 것이 좋았다.
- 무엇을 테스트할지 결정하는 것이 핵심이다 - 가능한 적게 테스트하라
- 개발환경/실행환경 설정에 관한 유닛 테스트를 하지 마라
- 화면 스타일에 관한 유닛 테스트를 하지 마라
- 유닛 테스트, 스냅샷 테스트, e2e 테스트가 모두 필요하다
- 유닛 테스트를 많이, 스냅샷 테스트는 조금만, e2e 테스트는 더 조금만 하라
TDD를 시작하면서 잘 해보려는 의욕 때문에 테스트 케이스를 가능한 많이 작성하려 했다. 특히 HTML 요소들이 화면에 제대로 표시되는지까지 유닛 테스트로 확인하려 했다. 이 책 덕분에 그러면 안된다는 것을 알게 됐다 (테스트 케이스는 가능한 적게 작성해야 하고, 화면 출력에 관한 테스트는 스냅샷 테스트로 커버해야 한다는 것을 알게 됐다).
