작성하려는 코드가 있다면 항상 먼저 어떻게 그 코드를 테스트할지 고민해야한다. 코드를 작성한 후에 어떻게 테스트할지 고민하기보다 작성할 코드를 묘사하는 테스트를 설계해야 한다. 이것이 테스트 주도 개발(TDD, Test Driven Development)에 기반을 둔 단위 테스트 전략의 핵심이다. TDD에서 단위 테스트를 시스템의 모양을 잡고 통제하는 도구로 활용해야 한다. 단위 테스트는 종종 잘 선별한 후 한쪽에 치워 놓고 나중에 반영하려는 코드가 될 수 있는데, 단위 테스트는 소프트웨어를 어떻게 만들어야 할지에 관한 잘 훈련된 사이클의 핵심적인 부분이다. 따라서 TDD를 채택하면 소프트웨어 설계는 달라지고, 아마 훨씬 더 좋은 설계의 코드가 될 것이다. TDD의 주된 이익 단위 테스트를 사후에 작성하..

단위 테스트, 혹은 여느 테스트 코드를 작성하는 일은 상당한 투자와 비용이 드는 작업이다. 하지만 테스트는 프로덕 코드의 결함을 최소화하고 리팩토링으로 프로덕 시스템을 깔끔하게 유지시켜준다. 그렇지만 역시 지속적인 비용을 의미하는 것은 부정할 수 없다. 시스템이 변경됨에 따라 테스트 코드도 다시 들여다보아야한다. 때때로 변경 사항들을 생겨나고 그 결과로 수많은 테스트 케이스가 깨져 테스트 코드를 수정해야 한다. 그렇다면 만약 테스크 코드가 굉장히 복잡하고 지저분하다면 어떻게 될까? 새로운 변경사항이 생겨날 때마다 테스트 코드를 수정하는 일은 더욱 더 힘든 일이 될 것이다. 그래서 이번 포스팅에서는 테스트 코드를 리팩토링하여 유지보수가 쉬운 테스트 코드를 만드는 것을 간단하게 소개할 것이다. 이번 포스팅의..

리팩토링(Refactoring)은 소프트웨어를 보다 쉽게 이해할 수 있도록 만드는 작업입니다. 이해하기 쉬운 코드가 수정하기도 쉽기 때문에 수정하기 쉬운 코드를 만든다는 또 하나의 목적 역시 자연스럽게 달성됩니다. 리팩토링은 들어가는 리소스를 최소화하기 위해서 외부 동작의 변화 없이 소프트웨어의 구조를 바꾸는 것을 중심으로 진행이 됩니다. 왜 리팩토링을 해야 하는가?리팩토링이 적절하게 진행되면 소프트웨어가 이해하기 쉬워지고 수정도 용의해 집니다. 여기서 얻을 수 있는 다양한 이익이 리팩토링을 해야하는 이유가 됩니다. 이해하기 쉽고 수정하기 쉬워지니 개발자의 개발 속도가 자연스럽게 빨라집니다. 그리고 이해하기 쉽기 때문에 버그가 있다면 훨씬 쉽게 발견할 수 있습니다. 리팩토링을 마친 다음 뿐만 아니라 코드..