나는 코드 개선 지침이라는 책을 읽었다.사고방식부터 구체적인 수법까지 모두 설명되어 있으니 정말 좋은 책이다.특별히 신경 쓰이는 부분에 관해서 나는 내가 설명한 내용을 기록하고 싶다.

책 소개

코드 개선 가이드(Object Oriented SELECTION)
저자: 마이클 C 페저스
발매일: 2009/7/14

생각

왜 시험이 필요합니까?

우선, 시작하는 몇 페이지에 쓴 다음 문장은 나를 놀라게 했다.
테스트되지 않은 코드는 나쁜 코드입니다.얼마나 잘 썼든 상관없어.얼마나 아름다운지, 얼마나 상대를 대하는지, 포장을 잘 하든 상관없다.테스트가 있으면 검증하면서 코드를 빠르게 변경할 수 있다.만약 시험이 없다면 코드가 좋은지 나쁜지 정말 모르겠다.
시험의 입도로 구상 방법 수준의 단일 시험.실행 시간이 짧고 오류를 식별하기 쉬우며 코드가 실제로 동작했는지 확인하는 것이 중요하다.

근무시간

테스트 용례의 인코딩은 간단하게 작업량을 증가시켰다.
이것은 다음 교체에 대한 투자로 다음 교체가 발생할 때 회수할 수 있다.다음에 없으면 회수할 수 없어요.
그리고 쓰지 않았지만 개발팀/환경에 따라 다음 교체까지 테스트 코드를 지속적으로 유지하는 것은 번거롭다고 생각합니다.
때로는 수동 테스트가 더 빠를 때도 있다.그러나 코드를 변경할 때마다 재테스트를 해야 한다는 점을 감안하면 전체 작업 원가를 고려할 여지가 있다.

시험장치

테스트 대상의 코드는 다음과 같은 구조가 필요하다.

검사: 테스트 결과에 접근할 수 있습니다.

분리: 테스트 대상을 테스트 대상 이외의 처리에서 분리하여 작업을 진행할 수 있다.

검사와 분리를 위해 테스트용 동작을 전환할 수 있는 곳을'접합부'라고 하는데 다음과 같은 종류가 있다.

프리프로세서 접합부: C나 C++ 언어와 같은 프리프로세서 기능을 사용하는 방법(주파수'소')

링크 연결부: C 또는 C++ 언어에서 늠카드, 자바에서 CLASSPATH로 전환하는 방법(주파수'소')

대상접합부: 클래스/인터페이스 계승, 방법을 활용한 과쓰기/과부하 방법(주파수'대')

테스트 코드 제작을 돕는 도구

자동 팩스 도구: Eclipse도 다양한 팩스 기능을 가지고 있다.

모듈 대상: Mockito/EasyMock/jMock 등이 있습니다.

단일 테스트 하네스: JUNIt/Nunit 등.

덮어쓰기 도구: 덮어쓰기 확인 도구에 대한 설명이 책에 없습니다.

오늘은 여기까지.
다음에는 실제 테스트 코드를 총결하고 싶습니다.