npm init vue@latest명령으로 Vue3와 Pinia를 이용하는 웹앱의 뼈대를 만듭니다.
$ node -v
v16.20.0
$ npm init vue@latest
Vue.js - The Progressive JavaScript Framework
✔ Project name: … todo
✔ Add TypeScript? … No
✔ Add JSX Support? … No
✔ Add Vue Router for Single Page Application development? … No
✔ Add Pinia for state management? … Yes
✔ Add Vitest for Unit Testing? … Yes
✔ Add an End-to-End Testing Solution? › No
✔ Add ESLint for code quality? … No
Scaffolding project in /home/ingee/work/todo/todo...
Done. Now run:
cd todo
npm install
npm run dev
1. Pinia 스토어에 있는 todo 목록을 화면에 표시하자
목표
Pinia 스토어에 todos라는 이름으로 todo 목록을 저장할 계획입니다.
Pinia 스토어에 저장되어 있는 todo 목록을 화면에 표시하는 기능부터 구현하기로 합니다.
Pinia의 초기 상태로 지정한 todo 목록이 화면에 표시되지 않는다고 합니다. 적절합니다.
❯ src/__tests__/App.spec.js (1)
❯ App.vue (1)
× shows todos in store
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
FAIL src/__tests__/App.spec.js > App.vue > shows todos in store
AssertionError: expected 'Todo Lorem Ipsum is simply dummy text…' to include 'wake up'
❯ src/__tests__/App.spec.js:35:30
33| const wrapper = createWrapper({ initialState })
34| for (const todo of todos) {
35| expect(wrapper.text()).toContain(todo)
| ^
36| }
37| })
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Test Files 1 failed (1)
Tests 1 failed (1)
Start at 13:08:02
Duration 90ms
FAIL Tests failed. Watching for file changes...
press h to show help, press q to quit
✓ src/__tests__/App.spec.js (1)
Test Files 1 passed (1)
Tests 1 passed (1)
Start at 13:11:57
Duration 108ms
PASS Waiting for file changes...
press h to show help, press q to quit
2. 입력창에 입력한 todo를 Pinia 스토어에 저장하자
목표
화면에 입력한 todo를 Pinia 스토어에 저장할 계획입니다.
todo를 입력하고 Add 버튼을 클릭하면, 해당 항목이 Pinia 스토어에 저장되게 하기로 합니다.
✓ src/__tests__/App.spec.js (2)
Test Files 1 passed (1)
Tests 2 passed (2)
Start at 13:45:47
Duration 160ms
PASS Waiting for file changes...
press h to show help, press q to quit
- 컴포넌트 . 통상 웹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가 바뀌어도 테스트 코드는 변경 없이 유지할 수 있다.
TDD를 시작하면서 잘 해보려는 의욕 때문에 테스트 케이스를 가능한 많이 작성하려 했다. 특히 HTML 요소들이 화면에 제대로 표시되는지까지 유닛 테스트로 확인하려 했다. 이 책 덕분에 그러면 안된다는 것을 알게 됐다 (테스트 케이스는 가능한 적게 작성해야 하고, 화면 출력에 관한 테스트는 스냅샷 테스트로 커버해야 한다는 것을 알게 됐다).