테스트 자동화 전에, 뭘 테스트해야 하는지부터 알아야

우리는 개발을 하면서 언제나 테스트를 합니다.

예컨대 폼을 만든다고 합시다. 그러면 처음엔 하나씩 값을 넣어 보며 제대로 저장이 되는지 테스트하겠지요.

밸리데이션 테스트도 할 겁니다. 필수값을 모두 비운 채 하나씩 채워가며 필수값이 없어도 폼이 넘어가는지 테스트할 겁니다.

테스트 케이스 코드를 짜야만 테스트를 하는 것은 아닙니다.

테스트 자동화로는 충분치 않습니다

그런데 이런 테스트에서 버그를 더 잘 잡아내려면 어떻게 하는 게 좋을까요?

단지 테스트를 자동화하는 것만으로는 충분하지 않다고 말할 수 있는 부분이 이 지점입니다.

자동화된 테스트를 100만 번 해도, 버그가 있는 값을 테스트하지 않는다면 테스트는 충분하지 않습니다.

그런데 후원금을 입력하는 폼이 있다고 쳐 봅시다. 이 필드의 최솟값은 1000원입니다.

이 필드는 어떻게 테스트해야 할까요? 1000을 입력해서 정상적으로 저장되면 테스트는 완료되는 것일까요?

진정 모든 것을 커버한 테스트는 1000부터 100만 원까지 1씩 올려가며 하는 테스트일까요?

아닙니다. 정상값을 여러 번 테스트하는 것은 큰 의미가 없습니다.

적어도 다음 값들을 테스트해야 할 것입니다.

이 숫자들은 각각 의미가 있습니다.

1000과 999는 최솟값 1000의 경계가 되는 값이므로 반드시 테스트해야 합니다.

0은 특별한 값이므로 반드시 테스트해 봅니다.

음수는 경계₍₁₀₀₀₎를 넘어간 값 중 특수한 값이니 한 번 해 봅니다.

그리고 무지하게 큰 수_{(이 경우 10의 25제곱)}와 작은 수_{(이 경우 마이너스 10의 25제곱, 0에 가까운 작은 값)}도 한 번 테스트해 보는 것이 좋겠습니다.

숫자로서는 정상 범위지만, 원화에서는 사용하지 않는 소수점을 사용한 값도 한 번 넣어 보고요.

숫자가 아닌 값_{(천 원)}을 해 보는 것도 중요합니다.

SQL 인젝션_{(Injection, 주입)} 공격을 염두에 두고 "_{(큰 따옴표)}나 '_{(작은 따옴표)}를 넣었을 때 에러가 나지 않는지도 한 번 해 봅시다.

이정도면 그래도 웬만큼 테스트했다고 할 수 있을 것 같은데요.

위 내용은 《지식 제로부터 배우는 소프트웨어 테스트》에 나오는 것을 일부 적은 것입니다. TDD를 기대하고 샀다가 그게 아니라서 실망했는데, 읽어 보고 나서는 오히려 정말 잘 샀다고 생각하게 된 책입니다.

제가 간단한 필드 하나로 예를 들어 설명했는데요. 이 책은 좀더 많은 내용을 다루고 있습니다.

우리는 평소에 자연스럽게 테스트를 합니다. 설계랄 것도 없이 무의식적으로 다양한 테스트를 하고 있을 겁니다.

이 책은 좀더 체계적으로 그런 테스트를 정리하고 설명합니다. 어떻게 하면 버그를 더 잘 발견하는 테스트를 설계할 수 있을지. 어떻게 하면 충분한 테스트를 거친 제품이라고 말할 수 있는지 말입니다.

이를 기반으로 하면 자동화된 테스트도 훨씬 더 잘 작성할 수 있을 겁니다.