유닛 테스트는 '테스트'가 아니라 '센서' 입니다.

테스트를 접해보지 않은 분과 대화를 나누다보면 테스트와 관련된 여러가지 이야기를 나누게 되는데요, 특히 테스트를 작성해야 하는 이유에 대해 이야기를 나누는 경우가 많습니다.

그러다보면 테스트가 실패했을 때 그리고 성공했을 때, 테스트는 어떤 것을 검증해야 하는지 등 많은 이야기를 매번 나누게 됩니다.

이번에 소개해드리는 글은 '테스트'가 코드에서 어떤 역할을 하는지 그리고 테스트의 성공과 실패는 무엇을 의미하는지 설명해주는 글입니다.

프론트엔드에서 테스트는 고비용 작업으로 많이 알려져있습니다. 하지만 테스트가 없기 때문에 이 글에서 소개하는 코드 수정으로 인한 '의도하지 않은 변경'이 발생하고 뒤늦게 발견하는 경우도 종종 마주합니다. 그래서 주의하자는 취지로 고비용의 꼼꼼한 QA가 포함됩니다.

프론트엔드에서 적정 수준의 테스트는 무엇인지 항상 고민합니다. 쉽지 않은 문제지만 그렇다고 포기하기엔 아쉽기도 합니다. 여러분의 의견은 어떠신가요?

이 글에서 인상 깊었던 몇몇 문장을 인용합니다.

If that were true, you’d need to write fewer tests as you got better at writing code, right? For a confident programmer, unit testing would soon start to feel like an unwelcome obligation imposed as part of a box-checking process.

"Unit tests are not about checking that the code works."

(당신이 코드를 잘 작성했다면 테스트는 적을 수록 좋은 게 맞다고 생각하나요? 확신에 찬 개발자라면 테스트 통과 표시는 그리 달갑지 않을 수 있습니다.)

It also needs to tell you exactly what you changed. If it’s something you intended to change, you can change the test to match. If it’s an accident, you leave the test as it is and go back to fix the production code.

Good unit tests are ones which separate the code cleanly into small pieces that can change independently. When a good unit test fails, it points directly at a specific piece of code or behaviour and says, “this changed: was that intentional?”

(내가 수정한 코드에 대해서만 테스트가 실패했다면 의도한대로 수정한 게 맞습니다. 만약 다른 유닛 테스트까지 실패한다면 의도하지 않은 코드가 영향을 받았을 가능성이 있습니다.)

When we write unit tests, what we’re really writing are change sensors.

(테스트가 아니라 센서라고 이해해보는 건 어떨까요?)