javascript testing의 best practice들을 모아놓은 글이다. production code에 대해서는 best practice를 많이 찾아보았지만, 테스트 코드는 어떠한 best practice가 존재하는지 명확히 알지 못했는데, 그런 면에서 도움이 많이 되는 글인 것 같다. 이 글은 javascript를 기준으로 쓰였지만, 언어를 막론하고 개발자라면 알아둬야 할 중요한 테스트 코드 작성 원칙에 대해 이야기하고 있으므로 많은 사람들에게 도움이 될 것 같다.

본인은 이 글을 읽으면서 다른 무엇보다도 section 0 부분이 가장 인상깊었다. 백엔드나 프론트엔드 등 분야에 상관 없이 테스팅 전체를 아우르는 대전제가 적혀있는 부분인데, 그 내용의 핵심은 바로 '테스팅은 간단해야 한다'는 것이다. 우리는 테스트 코드를 작성할 때 혹은 다른 사람이 짠 테스트 코드를 바라볼 때, 수학 문제를 풀 때와 같은 복잡함이 아닌 간단한 html 코드를 읽는 듯한 단순함을 느껴야 한다. 이 '간단한 테스트'를 위해 이런저런 best practice가 존재하는 것이다.

아래는 실제 section 0 부분의 글을 첨부한 것이다.

⚪️ 0. The Golden Rule: Design for lean testing

✅ Do: Testing code is not like production-code - design it to be dead-simple, short, abstraction-free, flat, delightful to work with, lean. One should look at a test and get the intent instantly.

Our minds are full with the main production code, we don't have 'headspace' for additional complexity. Should we try to squeeze yet another challenging code into our poor brain it will slow the team down which works against the reason we do testing. Practically this is where many teams just abandon testing.

The tests are an opportunity for something else - a friendly and smiley assistant, one that it's delightful to work with and delivers great value for such a small investment. Science tells us that we have two brain systems: system 1 is used for effortless activities like driving a car on an empty road and system 2 which is meant for complex and conscious operations like solving a math equation. Design your test for system 1, when looking at test code it should feel as easy as modifying an HTML document and not like solving 2X(17 × 24).

This can be achieved by selectively cherry-picking techniques, tools and test targets that are cost-effective and provide great ROI. Test only as much as needed, strive to keep it nimble, sometimes it's even worth dropping some tests and trade reliability for agility and simplicity.