2014.12.07 23:38
Testing and Refactoring with legacy code



테스트를 하기 위해서 첫번째로 테스트 해야 할것은 얕은 브랜치부터 깊은 브랜치로 가야 하고, 
리펙토링은 깊은 곳에서 부터 얕은 곳으로,.
start testing from shortest to deepest branch, start refactoring from deeptest to shortest branch.
(단순히 물리적인 인덴트 뿐만 아니라 논리적인 의존성도 생각한 것을 생각해줘야 함)

인젝션이나 등등의 의존성때문에 테스트가 힘들다면, 그 부분을 따로 메소드로 뽑아내고, 테스트 클래스에서 테스트 대상이 되는 클래스를 상속한뒤, 그 인젝션이 되는 메소드를 오버라이드 하고, 목 또는 페이크 오브젝트를 전달하여 비즈니스로직을 테스트 한다. 

코드 커버리지를 확인해 가면서 테스트가 제대로 커버하는지를 확인하는것도 좋은 방법이다.

null 도 또한 의미있는 이름을 지어서 상수로 두는것이 좋다. 테스트를 이해하는데 도움을 주기 때문.

테스트 케이스를 위해 여러가지를 set해야 할땐 빌더 패턴을 적용하면 편리하다. 나중에도 써먹을 일이 생기기 때문, 가독성에도 좋다.

UserBuilder
.aUser()
.friendsWith(ANOTHER_USER, loggedInUser)
.withTrips()
.build();

aUser(){
return new UserBuilder();
}

가변인자로 받으면 편리하다. 

for 로 돌면서 플래스 셋을 위해서(리스트에 포함되 있는지 확인하는, 이런것은 contains를 활용하면 좋지) break 를 하는데 이게 왜 필요할까? 이런것은 물어보지 말고 하라고 시켜야 한다. 

분기에 따라서 어떤 객체를 만들어서 그 리턴할때, 아래에서 두번재 if 블록.
이렇게, 이를 다시
 
이렇게 삼항 연산자로 바꾼다.
물론 이것이 가독성이 나쁠 수 도 있는데, 상황에 따라서 선택하면 좋을듯.
그리고 저 new ArrayList() 를 상수로 만든다. 또는 그냥 메소드 추출.
이때 테스트와 프로덕션 코드와 비슷한 맥락, 으로 이어지면 이해하기 좋다. 물론 영어를 잘한다면.

인덱트를 줄이기 위해 if문 판단을 미리 하거나 나중에 하거나??? 분리를 한다. 이렇게 분리를 하게 되면, 메소드 안에 크게 두가지 블록으로 나눠지게 되고 이를 각각으로 나누면 좋다.

의존성을 줄이기 위해 인자로 받을 수 있는것은 인자로 바꾼다. 

59:22 까지 봄.


저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'[+++ JAVA +++] > - - 작성중' 카테고리의 다른 글

Mockito 를 이용한 Callback test  (0) 2014.12.08
Testing and Refactoring with legacy code  (0) 2014.12.07
The Art of UNIX Programing  (1) 2014.12.07
Skip List, Bloom filter  (0) 2014.12.07
Trackback 0 Comment 0


티스토리 툴바