유닛테스트 자주하라고 하는데
이게 UI쪽은 짜기가 불가능할 뿐만아니라,
이 UI가 잘 유저한테 보여지도록 그려지는지?
이를테면 자전거 트랙킹앱을 만든다고하면 지도위에 선이 표시되는걸 테스트하기가 참..
난감할거같다 이거임..
또한 논리적인 오류를 잡아낸다고 하더라도
모든 경우의 수는 테스트 못하는것인데
솔직히 오류라는것이 정말로 예기치 않은 상황에서 잘 발생하지,
테스트 환경같은데서 발생하겠음..?
결론은 논리적인 오류도 잡아낸다는것도 아주 제한적인 상황밖엔 못한다는 이야기가 되는것같음
위와 같은 상황을 어떻게 해결해야할까..
TDD로 해결할 수 있는데 내가 뭘 모르고있는거?
UI는 이미지 기반 UI 테스트 프레임워크가 있음.
그리고 논리적인 오류와 경의의 수 같은 경우는
TDD를 하는 이유를 생각해 봐야 함. 개인적으로 TDD가 주는 가장 큰 장점은 코드 상에 변화가 있을 때 side effect 에 따른 오류 여부를 한 번에 테스트할 수 있다는 것으로 생각함 커버리지와는 미묘하게 다름..
모든 케이스에 테스트를 넣는 건 기본이지. 몇 개 빼먹을 수도 있지만 그렇다고 TDD가 의미가 없어지는 건 아니라는..
ui 프로그래밍에 tdd 적용하는 건 나도 옛날에 고민했던 부분인데 그냥 모듈 아니면 tdd 못한다고 생각하는 게 편해. 그리고 그게 tdd 확산이 지지부진한 이유 중에 하나이기도 함.
그렇구먼 한번에 이해가 확 됨!
보통 자스민이라는 거 쓰지 않음? 자바스크립트 테스트지만
아님 qunit이라던가 근데 어떤 행위기반의 테스트면 자스민이 나은듯