22. 기존의 버저닝 규칙
X.Y.Z
!
1. 특별한 규칙을 가지고 있지 않음.
2. 개발자가 많이 변경된 것 같다고 생각하면 좀 많은 버전을 올림.
23. Semantic Versioning
X.Y.Z
!
1. 기존 버전과 호환되지 않게 API가 바뀌면 X(major)을 올린다.
2. 기존 버전과 호환되지만 API 추가된 경우 Y(minor)을 올린다.
3. API 변경 없어 버그만 수정된 경우 Z(patch)을 올린다.
[http://semver.org/]
아쉬운 점
1. 크기를 알기 힘들다. (10개 수정 == 1개 수정)
2. 버저닝의 규칙만으로 결과를 확인하기 어렵다.
24. 여전히 업그레이드는 걱정
버전간 차이가 크면 릴리즈 노트는 큰 도움이 안됨
https://www.flickr.com/photos/samstanton/3541463682
25. 가보지 않은 길은 막막하다
Q&A
https://www.flickr.com/photos/samstanton/3541463682
39. Core - 테스트
Cloud 환경은 제외
- 빠르게 확인 안됨
JSTestDriver
- 자체 도구에 맞게 Adapter 구현이 안됨
필요한 기능만 개발
- 그냥 쉽고 빠르게 응답받는 걸 만들자
40. Core - 테스트
file write
Ajax polling
result
$Ajax
$Element
$A
$H
41. Core - 테스트
Testem [https://github.com/airportyh/testem]
Karma [http://karma-runner.github.io/0.12/index.html]
Adapter의 방식이 Event로 되어 있어 타 단위 테스트 라이브러리와 연동이 잘됨
42. Component (Mobile) - 테스트
단위 테스트 테스트 케이스
!
1. 단위 테스트는 크게 문제가 되지 않는다
2. 사람이 직접 테스트해야 하는 테스트 케이스 경우 비용이 크다
43. 밀도있게 하자
어떻게 하면 줄일 수 있을까?
1. 대부분의 문제는 수치화 안되는 상황
2. 실제 사용자 이벤트가 필요한 경우
3. 퀄리티와 직결되는 이슈
https://www.flickr.com/photos/ores2k/394359583
44. 기능별로 구분할까?
테스트 케이스 테스트 케이스 테스트 케이스
A컴포넌트 B컴포넌트 C컴포넌트
A기능 B기능 C기능 D기능
45. 테스트 리팩토링
테스트 케이스
겹치는 테스트 케이스
- 비슷한 동작을 하는 경우 하나로
40%
비슷한 기기의 통합
46. 46
운영하는데 유연성은 중요
테스트 케이스가 좋은 장치
단위 테스트 케이스 - 도구를 활용
테스트 케이스 - 밀도가 중요
57. 분리하는게 좋겠다
jindo.$Fn.prototype.bind
=
function()
{
if(Function.prototype.bind){
//bind가
있는
경우
}else{
//bind가
없는
경우
}
};
if
(!Function.prototype.bind)
{
Function.prototype.bind
=
function
(target)
{
//
bind가
없는
경우
};
}
!
jindo.$Fn.prototype.bind
=
function()
{
//
bind가
있는
경우
};
58. 분리하는게 좋겠다
Core
Component
Mobile
Component
Component Core
polyfill
Core
Component Mobile
Component
Component Core
59. 진행중
!
1. polyfill의 지원은 잘되어 있는 편이라 보다 쉽게 간접적으로 외부지원을 받는다.
2. 생각보다 많은 작업이라 한번에 진행하긴 힘들고 천천히 진행중이였다.
가장 많이 사용하는 core 최신 Component
최신 core 전 버전 Component
최신 core 최신 Component