수동테스트
- QA 담당자가 UI를 사용해서 기능을 검증하는 것
- 최종 사용자의 경험과 가장 유사하고 인수테스트로 많이 사용
- 다른 기법에 비해 상대적으로 실행 비용이 높고 결과의 변동이 큼인수테스트
- 배치된 시스템을 대상으로 검증
- 전체 시스템 이상여부 신뢰도가 높음
- 높은비용
- 피드백 품질이 낮음
- 문제가 있는지는 알 수 있는데 그 문제가 어디서 왜 발생했는지 투명하게 넘어오지 않음
- 스무고개처럼 하나하나 질문해야 문제사항을 파악할 수 있음단위테스트
- 시스템의 일부 대상으로 검증
- 테스트 작성하는 비용이 낮음 (작성/실행/관리 비용)
- 높은 피드백 품질 -> 오류 메시지가 정확
- 전체 시스템에 이상이 있는지 없는지 신뢰도가 낮음 -> 단위테스트가 성공한다고 해서 전체 시스템에 이상없다는 보장없음소프트웨어 회귀
- 원래 동작하던 기능이 어느 시점 이후로 동작이 안 하게 되는 것
- 회귀테스트 대상은 시간이 갈 수록 늘어난다.코드 재사용
- 반복되는 문제의 풀이는 재사용 가능
- 전혀 수정하지않고 그대로 재사용되야함.
-> 조금이라도 수정하는 경우 수정으로 인해 발생할 문제 예측이 힘들다
- 소프트웨어 개발 비용 절감모듈화
- 분해
- 큰 시스템 -> 작은 하위 시스템 분해가능
- 교체 가능
- 조립
- 작은 시스템 -> 큰 상위 시스템 조립 가능
- 모듈 재사용
- 라이브러리
- 단위테스트반복되는 테스트 코드
- 중복을 제거해서 테스트코드 양을 줄인다고 무조건 좋은건 아님. 오히려 피드백이 낮아져 테스트 신뢰도도 낮아질 수 있다
- jest의 경우 파라미터를 지원해서 중복을 줄이면서 피드백도 높이는 방식으로 테스트 가능테스트코드
- 눈에 보이고 구체적인 목표, 자가검증 가능하고, 반복실행가능하며, 결국엔 운영코드api의 클라이언트TFD
- Test First Development
- 운영코드보다 테스트 코드를 먼저 작성
- 참고블로그에서 보면 TDD 는 테스트 우선으로 코드를 개발하고 리팩토링을 반복하는 과정참고 : https://firstcheck.tistory.com/75
정리된 코드 - 리팩토링 + 자동화된 테스트 케이스
- 생산성, 지속성 -> 코드는 작업환경, 작업결과물 -> 오늘 작업한 코드는 내일 작업환경 -> 작업환경을 정리 = 리팩토링!
- 리팩토링은 원래의 의미를 훼손하지않으면서 구조를 바꾸는 작업
- 의미가 바뀌지않는다는걸 어떻게 확인하는가 ?
=> 테스트(수동테스트, 자동화, 인수/단위테스트가 됐던 여러 테스트)테스트 주도 개발
Red, Green, Refactor
- Red : 실패하는 테스트 추가
- 실패함을 확인해야 테스트가 동작함을 믿을 수 있음.
- 운영코드를 아직 수정하지 않았기때문에 실패하는 것을 확인해야함.
- Green : 테스트 통과, 최소한의 코딩
- 추가된 테스트 및 모든 테스트가 성공해야함
- 테스트 성공은 요구사항 만족을 의미 - 가장 필요한 것
- 테스트 성공을 위한 최소한의 변경
- Refactor : 구현/설계 개선, 테스트 통과 유지
- 코드베이스 정리
- 가독성/적응성/성능
- 모든 테스트 성공을 전제켄트 백 설계규칙
- 테스트 통과
- 의도 노출 ( 가독성) - 아래 중복제거와 동일한 우선순위
- 중복 제거
- 가장 적은 요소
- 테스트 통과에 필요하지 않은 코드는 다 제거해라프로그래머 피드백
- 사용자 피드백
- QA
- 프로그래머 테스트
- 도구 피드백오버엔지니어링
- 목표에 필요하지 않는 코드성능을 위해 덜 중요한 목표에 프로그래머 자원을 쓰는 것TDD 핵심은 피드백
- 정해진 절차가 아닌 짧은 주기로 지속되는 피드백을 받는 것후기
- TDD가 이렇다더라 하는 산재된 지식을 정리할 수 있는 계기
- 즐겁게 강의하시더라..
- 특히 정리된 코드 챕터에서는 테스트하고 리팩토링 하는것이란 어떻게 하는 것인지 확실하게 본 것 같아서 특히 그 챕터는 알찼다고 생각한다.
재활훈련 중