도입
tl;dr red - green - refactor
어디 보낼글 아니니 반말로 써야지.
테스트 안하는 사람들의 논리는 몇가지 패턴이 있다.
- 바빠서 못해요.
- 나는 테스트에 가치를 발견하지 못하겠다.
- 테스트할 만한 가치가 없는 부분이에요.
- 변경이 너무 잦아서 의미가 없어요.
위에 있는 경우는 뭐 설득당할 생각이 없거나 여유가 없는거라 어쩔 수 없는데 오늘
설득 가능할 것 같은 새 패턴을 발견해서 여기에 대한 이야기를 해볼까한다.
- 테스트하려고 설계를 망치긴 싫어요.
읭??
좋은 설계라구?
테스트충으로써 tdd를 하면 많은 메서드와 비대한 객체로 끌려가는 건 안다. 다만
그걸 리펙터링할 타이밍을 못잡는 상황이 문제인거지 이게 tdd의 문제라 생각하지는
않는다. 오히려 중요한 부분인데 설계 문제로 테스트를 못한다면 난 설계에 대해
다시 고민하지 테스트를 줄여서 좋은 설계를 만들자는 주장은 안할 것 같다.
좋은 테스트가 좋은 설계를 보장하지 않지만 모든 좋은 설계는 좋은 테스트를 가지고 있다
가령 지금 테스트를 줄여 이쁘게 코드가 나왔다고 해도 코드는 고정된 자산이 아니다.
많약 그런식으로 고정할 수 있는 코드라면 그냥 한번 잘짜면 되지 에초에 테스트도
필요없다.
그래서 테스트 팁
뭐든 많이해보고 익숙해 지는 게 최고다. 굳 올드 red-green-refactor만큼 좋은 bp를
본적이 없으니 그거 그냥 하자능.
1. red
아는 범위에서 최대한 신중하게 최소 스팩을 정한다. 설계를 꼼꼼히 하고 싶다면 이
단계에서 해라. 단위 테스트를 먼저하느라 설계가 이상해진다면 통합 스팩을 먼저
작성해라. bdd를 한다면 문장을 만들어서 기획자한테 내가 이해한게 니가 기획한거랑
일치한지 확인하는게 좋다. 근데 생각해보면 기획자의 경험이나 이해도는 내가 어떻게
할 수 있는 게 아니긴하다.
2. green
아는 범위에서 최대한 구현한다. 모르는 건 어쩔 수 없다.
3. refactor
모든 코드가 적절한지 고민하고 필요없는 부분은 늦기전에 지운다. 딱히 정답이 있는
부분도 아니고 경험이 잘 설명될 수 있는 부분도 아니고 이게 젤 힘들다.
이게 잘 안되서 설계가 어쩌느니 테스트가 어쩌느니 궁시렁 되는데 나한테 권한이
있고 이유를 설명할 수 있다면 모든 코드는 수정 가능하다는 마인드 셋이 가장
중요하고 그 다음은 대량의 코드 수정을 어느정도의 효율로 할 수 있는가 정도
아닐까. 대부분 리뷰에서 수정사항 대량으로 나오면 힘들어하는게 저쪽이라…
그밖에
- OOP 한정이지만 프라이빗은 테스트하는 거 아님.
프라이빗이 테스트하고 싶어진다면, 객체를 나눌때가 된게 아닌가 고민해 보라능. - 테스트할 때 의존관계 너무 많이 만드는 거 아님. 인생은 테스트 기다리며 지내기엔
너무 짧다. - 너무 완벽하려 노력하지 마라. 에초에 내 실력으로는 택도 없다. 할 수 있는
범위에서 최대한 하는거지 뭐… - 깔끔하게 개선되었을 때의 기분좋은 감각을 기억하라능.
- 일하는게 너무 헬이라 생각되면 불평하면서 계속다니지 말고 깔끔하게 이직하라능.
자는 시간 빼고 80% 정도를 일하면서 지내는데 즐겁기라도 해야지. - 개발자끼리 의견 일치를 못볼때 설득하는 거보다 짜서 보여주는게 효율적임.
내가 많이 당했는데 별로 맘에 안들어도 완성품 들고오면 리젝하기 힘들더라.