그런거 없다! 코드여 터져라! 폭발은 예술이다!

제목 그대로 입니다.
이 글을 읽고 있는 당신은 작성한 코드가 제대로 동작한다고 어떻게 확신하십니까?

코드가 언제 터진다고 생각하나?

원시적인 방법

• 하나씩 다 눌러본다.
• 모든 기능을 다 직접 눌러 점검한다.

이 방법으로 하면 개발자는 코드도 작성해야 하고
그 때 마다 어떤 기능에 문제가 생겼을지 모르기 때문에
전부 점검해야 하는데 그럴 시간도 없습니다.

결국 QA를 해야하는 사람이 따로 생기게 되고,
개발자는 곧 욕먹는 사람으로 전락하기 쉽상입니다.

이 방법으로 반복적으로 QA를 하면 지옥이 펼쳐집니다.
무언가를 확인하기 위해선 로그인을 하고, 입장을 누르고, 채널을 선택하고, 캐릭터를 고른 뒤, 월드에 입장하고, 기능이 발동하는 곳 까지 가서 확인해야 합니다.

웹도, 게임도, 백엔드 서버도 모두 마찬가지입니다.
개발하면서 확인하는게 불가능할 지경이죠.

하루종일 반복 노가다를 할 수 있어

반복 노가다를 대신 해주는 매크로

• 테스트 해야 하는 지점까지 반복작업을 해주는 매크로를 작성한다.
• 코드를 변경할 때 마다 매크로를 켜서 확인한다.

조금은 나은 방법이지만 매크로가 노가다를 대신 해줘도 시간은 비슷하게 소모됩니다. 대신 힘은 덜 들겠죠.

하지만 이래나 저래나 크게 개선되는건 없을겁니다.
문제가 생기면 어디서 문제가 생긴건지 상황을 확인하고 코드를 일일이 재검토 해야겠죠.
여전히 시간은 부족하고, 제대로 확인하지 못하고 QA에 넘겨서 욕을 듣고 있겠지요.

크크, 아무리 해도 끝이 없을거다

무한 분열

• 발생하는 이벤트마다 프로젝트 단위로 분리하여 거기서 실행하여 테스트 합니다.

조금 더 낫긴 합니다.
기능을 확인하는데 드는 시간이 더 줄어들겁니다.

대신 이벤트마다 프로젝트를 새로 생성해서 해당 코드를 거기로 복사한 뒤 실행 가능한 상태로 가공하여 테스트 하는건 엄청나게 번거롭고 귀찮을겁니다.

그리고 원본 코드를 바꾸고나면 테스트용 프로젝트쪽에도 복사한 코드를 수동으로 변경해줘야겠죠.

아까보단 낫지만 나이스하진 않습니다.
그래도 이렇게라도 하면 적어도 코드가 잘 작동하리라는 확신은 가질 수 있습니다.
안하는 것 보다는 훨씬 낫죠.

침착하자. 「테스트 코드」를 작성하면서 마음을 가다듬자
「테스트 코드」는 대상과 자기 자신밖에 없는 고독한 코드...
내게 용기을 불어넣어 준다...

TDD

• 테스트 코드를 작성해가며 테스트에 만족하는 코드를 완성시킵니다.
• 코드를 작성/변경 할 때 마다 자동으로 테스트를 돌려 확인합니다.

가장 이상적인 방법입니다.
유명한 테스트 도구들이 많습니다.
jUnit, Gomega, jest, cypress 등등...

테스트 코드는 용기를 불어넣어 준다 코드를 작고 심플하게 만드는데 도움을 줍니다.
복잡한 함수를 테스트 하려면 spy나 mock 등을 복잡하게 만들어야 하는데,
그 순간에 테스트 대상이 너무 복잡하다는걸 깨닫고 단순하게 분리하게 되죠.

그리고 테스트 코드를 작성했다면, 코드를 변경했을 때 어떤 문제가 발생하는지 즉각적으로 알 수 있습니다.

TDD를 통해 완성한 코드는 잘 작동한다는 확신을 가질 수 있습니다.
코드도 작고 심플한 조각들의 완성체가 되기에 유지보수에도 좋습니다.

깨알 홍보타임

이 글은 @belivvr/aframe-react 라이브러리를 완성하며
커버리지 100%를 달성하여 codecov 뱃지에 100% 찍힌게 뿌듯해서 쓰는 글입니다.

A-Frame 의 모든 레퍼런스와 프로퍼티를 제대로 지원하는 유일한 React 라이브러리 입니다.

없어서 답답하니 제가 쓰려고 만든것도 있지만, VR과 메타버스 개발에 유용한 도구로 활용해주시길 바라며 홍보를 마칩니다.

많은 관심 부탁드립니다. 감사합니다.