개발 서적/일일 독서
[독서 일기] 2023-04-16 (일)
p.116~127 계약에 의한 설계. 사전 조건(메서드가 받아들인 입력값 검증), 사후 조건(메서드가 다른 메서드에 약속한 것을 반환하도록 보장) 단언 키워드, assert. 강한 조건과 약한 조건. 불변식, 생명주기 전체에서 유지되어야 하는 것.
개발 서적
개발 서적/일일 독서
[독서 일기] 2023-04-15 (토)
p.100~115 100%의 테스트 커버리지가 시스템을 제대로 테스트했다는 것은 아니지만, 커버리지가 매우 낮다는 것은 시스템이 제대로 테스트되지 않았다는 것이다. 어떤 커버리지 기준을 사용할 것인지 결정. 돌연변이 테스트는 일부러 버그를 주입에서 테스트가 깨지는지 확인한다. 비용은 비싸지만 유익하다.
개발 서적/일일 독서
[독서 일기] 2023-04-14 (금)
p.213~226 자바스크립트에서 함수형 프로그래밍을 활용한 주요 함수 apply, 커링, bind, 래퍼, 반복 함수(each, map, reduce) 어떻게 구현했을까를 생각해 보고 이해하는 게 도움이 많이 되는 것 같다.
개발 서적/일일 독서
[독서 일기] 2023-04-13 (목)
p.91~99 반복문을 처리할 때는 요구사항에 대한 충분한 이해 필요. 테스트에는 트레이드오프가 있다. 테스트를 작성하고 코드 커버리지를 보면 놓칠 수 있는 구획과 경계를 찾을 수 있다.
개발 서적/일일 독서
[독서 일기] 2023-04-12 (수)
p.77~90 소스 코드를 활용해서 테스트 스위트를 확장하는 것, 구조적 테스트. 코드 커버리지를 통해 테스트 코드가 어느 부분을 수행하는지 쉽게 찾을 수 있다. 코드 커버리지에는 다양한 기준이 있다. 모든 조합을 테스트하기보단 중요한 조합을 찾는다.
개발 서적/일일 독서
[독서 일기] 2023-04-11 (화)
p.36~76 명세 기반 테스트. 요구사항을 테스트의 입력으로 사용한다. 다양한 케이스를 작성한다. 특히 버그는 경계를 좋아한다. 명세 기반 테스트를 작성하기 위한 7가지 단계를 제안한다. 프로그램에서 실패를 할 경우에 비용이 큰 부분은 테스트 비용을 많이 투자한다. 모든 테스트 케이스를 작성할 수 없다. 무엇을 테스트할지 결정한다. 테스트 스위트를 강화하는데 창의성과 경험이 중요하다. 테스트를 잘 작성하기 위한 제안, 역시나 경험이 많이 중요한 것 같다.
개발 서적/일일 독서
[독서 일기] 2023-04-10 (월)
~p.35 소프트웨어 테스트의 전부는 버그 찾기. 효율적이고 체계적인 소프트웨어 테스트. 도메인 테스트. 구조적 테스트. 예시 기반 테스트. 속성 기반 테스트. 테스트를 한다고 버그가 없을 수 없다. 치명적 버그를 줄이는 것. 검증과 유효성 검사. 단위 테스트 - 통합 테스트 - 시스템 테스트
개발 서적/일일 독서
[독서 일기] 2023-04-09 (일)
p.191~212 객체 지향 프로그래밍 - ES5로만 구현하기에는 지금 보기엔 불편해 보인다. 함수형 프로그래밍 - 순수 함수, 고계 함수, 클로저. 메모이제이션 패턴, 함수의 프로퍼티에 계산값을 저장.
