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

이번 포스팅에서는 목(Mock) 객체를 사용하여 테스트하기 힘든, 혹은 외부환경과 의존성을 끊는 테스트를 하기 위한 방법을 간단하게 다루어 볼 것이다. 여기서 다루는 목(Mock)객체는 정말 단순한 수준의 예제이다. 결과적으로 이번 포스팅의 목적은 목객체는 무엇이고 왜 사용하는 지에 대한 내용이 될 것 같다. 지금 진행할 예제는 크게 코드 내용 자체를 알필요?는 없을 것 같다. 이 말은 우리가 개발하며 테스트를 작성할 때, 코드의 내용을 몰라도 된다는 말이 아니다. 테스트 작성은 당연히 코드의 내용을 빠삭히 알고 작성해야 하는 테스크이기 때문이다. 필자가 말하는 "알 필요는 없다"라는 것은 이번 포스팅은 독자들과 같이 애플리케이션을 개발하며 테스트를 작성하는 포스팅이 아니고 어느 순간에 목객체를 사용해야..

우리가 직접 작성한 코드라고 하더라도 단순히 메서드, 클래스 코드를 보면서 숨어 있는 버그를 찾아내는 것은 거의 불가능하다. 물론 코드를 살펴보는 것도 하나의 버그를 찾아내는 행위이긴 하다. 하지만 효율적인 단위 테스트를 통해 숨어있는 버그를 찾아내는 것이 훨씬 더 효율적인 방안일 듯하다. 그렇다면 테스트를 수행하는 것 만큼 중요한 것은 무엇일까? 아니, 올바르고 더 효율적인 테스트를 수행하기 위해 받침이 되는 행위가 무엇일까? 바로 테스트 케이스! 무엇을 테스트 해야할까를 고민하는 것은 아주 중요하고 여기서 그치는 것이 아니라 정말 중요한 테스트 케이스를 찾아 테스트에 적용해야한다. Right-BICEP는 우리에게 무엇을 테스트할지에 대해 쉽게 선별하게 한다. Right : 결과가 올바른가? B : 경..

단위 테스트를 작성하는데 있어서 FIRST 속성을 지킨다면 더 좋은 단위테스트를 작성할 수 있다. 그렇다면 FIRST 속성이란 무엇일까? Fast : 빠른 Isolated : 고립된 Repeatable : 반복 가능한 Self-validating : 스스로 검증 가능한 Timely : 적시의 일반적인 단위 테스트를 작성하던 TDD 개발 방법론을 이용하던 FIRST 원리를 고수하면 더 나은 테스트 코드를 작성하는 데 도움이 된다. 1)Fast : 빠르게 테스트 코드를 느린 로직에 의존하지 않고 테스트를 빠르게 유지한다. 조금더 클린한 객체지향 설계에 맞춰 애플리케이션이 설계된다면 조금더 나은 테스트 코드를 작성하기 좋아진다. public class StatCompiler { static Question q..