Blackbox and Whiteboxtest란? 블랙박스 테스트 와 화이트박스 테스트?

Blackbox and Whiteboxtest란? 블랙박스 테스트 와 화이트박스 테스트?

 

개발을 한다는 것은 소스코드를 단지 작성하는 것에 그치지 않습니다.

개발을 위해 행해지는 모든 행위와 과정들이 사실 개발을 한다는 것이라 할 수 있습니다.

이는 예를 들면, 고객으로부터 요구사항을 듣고 분석하여 기능적으로 구현 가능한지 판단한 뒤, 디자인을 마치고 개발한 뒤 테스팅을 거쳐 마지막 고객에게 결과를 가져다주는 것입니다. 이중 오늘은 테스팅에 관해서 좀 더 자세히 유닛 테스트에 관해서 알아보려 합니다.

 

1. 테스트 왜 필요한가?
2. 유닛 테스트란?
3. Jest.js란?
4. 마치며.

 

1. 테스트 왜 필요한가?

테스트란 무엇일까요??
이는 누구나 당연히 생각하듯 코드가, 프로그램이, 결과가 제대로 작동하고 보이고 도출되는지 확인하는 작업입니다.

그렇다면 어떻게 이루어져야 할까요??

이는 크게 두 가지의 관점으로 이루어집니다. 즉 개발자의 관점과 사용자 혹은 제삼자의 관점입니다.

이를 좀 더 전문적으로 Whiteboxtest와 Blackboxtest라고 부릅니다.

Whiteboxtest는 개발자의 관점에서 이루어지는 테스트들을 뜻하며,

당연히 Blackboxtest는 사용자의 관점에서 이루어지는 테스트를 말합니다. 

이 둘의 가장 큰 차이는 소스코드 즉 구조적, 기술적 작동방식을 알고 테스트하느냐 모르고 테스트하느냐에 차이입니다.

즉 Whiteboxtest는 개발자의 관점에서 코드가 어떻게 구성되었고 작동해야 하는지 기술적인 구현을 이미 알고 있는 상태입니다.

반대로 Blackboxtest에서는 사용자의 관점으로써 작동이 제대로 이루어지는 판단하는 것입니다.

 

즉 다시 말해 Whiteboxtest의 경우 프로그램이 내부적으로 어떻게 이루어져 있고, 작동하는지 알고 있는 상태에서 테스트하는 것이며,

Blackboxtest의 경우 내부적으로 어떻게 작동하는지는 모르지만, 제대로 작동하는지 테스트하는 것입니다.

이러한 두 가지 큰 틀은 당연히 여러 테스트들로 나뉩니다.

 

그렇다면 테스트는 꼭 필요할까요??

결과적으론 그렇다일 것입니다. 하지만 회사의 규모 혹은 프로젝트의 규모에 따라 테스트를 생략하는 곳도 있습니다.

하지만 프로그램을 개발한다는 것은 당연히 퀄리티 또한 보장이 되어야 합니다

이때 퀄리티란 보안, 작동시간, 항상 동일한 작업을 수행하고 같은 결과를 도출하는지, 오류는 없는지, 예외를 해결 가능한지 등등 많은 부분을 다루게 됩니다. 

 

 

2. 유닛 테스트란?

테스트하면 가장 기본이 되는 테스트가 유닛 테스트입니다.

이는 가장 작은 단위의 테스트이며 Blackbox테스트 중 하나입니다.

즉 개발자 관점에서 이미 코드가 어떻게 짜여있고, 어떤 식으로 프로그램이 실행되는지 로직을 알고 있는 상태로 실행되는 테스트입니다.

유닛 테스트에서 가장 작은 단위의 메서드들이 테스트됩니다. 또한 우리는 리액트를 이용할 것이기에 컴포넌트들도 테스트되어야 합니다.

개발자는 유닛 테스트를 통해서 크게 오류의 유무를 판단하기도 하지만 작성한 코드가 의도한 대로 작동하는지 그리고 일정한 값을 반환하는지 등을 알아볼 수 있습니다. 컴포넌트의 경우, 컴포넌트가 존재하는지, 어떤 내용을 포함하고 있는지, 몇 개의 컴포넌트가 렌더링 되었는지 등등을 알아볼 수 있습니다.

 

이를 위해서 기본적으로 리액트에서 jest.js와 react testing library를 사용합니다. 

이는 우리가 create react app을 이용하여 프로젝트를 생성할 때 포함되어있는 모듈입니다.

이를 확인하기 위해서 개발자는 프로젝트에서 명령어 npm test 혹은 yarn test를 통해 jest가 문제없이 실행되는지 알 수 있습니다.

 

 

3. jest.js?

앞서 언급한 create react app을 통해 리액트 프로젝트를 생성할때 자동으로 포함되어 설치되는 모듈입니다.

 

처음 또 다른 모듈의 사용방법을 배우려면, 그것도 테스트 모듈을 배우려면 먼저 스트레스부터 다가올 것입니다.

하지만 걱정 마세요!! jest는 정말 직관적이거든요.

하지만 배워야 하는 부분은 상당히 많습니다. 오늘은 jest.js라는 것이 있다는 것만 알고 가셔도 충분합니다.

그리고 저 또한 방대한 내용을 오늘 이 글에 쓰지 않을 것입니다. 대신 다음 글에 조금이라도 쉽게 사용하실 수 있도록 작성해보겠습니다.

 

 

4. 마치며.

사실 테스팅이라는 게 참 귀찮습니다.

이미 나는 내가 작성한 코드가 어떻게 작동하는지 알고, 로컬에서 작성한 코드를 직관적으로 볼 수 있는데, 왜 또 테스트 코드를 작성해야한다니, 개발 다 해놓고 또 이에 맞는 테스트코드를 작성하려면 머리가 또 아파옵니다.

하지만 개발자로서 가장 중요한 것은 증명하고 남들도 이해할 수 있도록 코드를 작성하고 또한 테스트를 통해 증명하는 것일 것입니다.

또한 이를 통해 코드의 퀄리티도 높아질 것입니다.

저도 처음에는 컴포넌트가 렌더링 되었는 걸 직관적으로 볼 수 있고, 버튼을 눌러보면 메서드가 실행되는걸 바로 확인 가능한데 왜?? 또 테스트 코드를 따로 작성해야되지??? 싶었습니다. 하지만 스스로 작동하는것을 확인하고 마는것과 그걸 테스트코드를 통해서 항상 검증하는 것은 큰 차이이며, 또한 이러한 와중에 의도하지 못한 버그 혹은 에러를 찾는 경우가 정말 많습니다.

또한 이는 협업에서도 빛을 발하게 됩니다. 그 이유는 제가 어떠한 작업을 수행하고 관련된 관련된 컴포넌트가 제가 작성한 코 스로인해서 에러를 유발하게 될 수 있으며, 이는 테스트를 통해 검증하지 않으면 어떠한 다른 문제를 야기할지 모르기 때문입니다.

 

예로 이번 주에 다른 팀과 작업하는 과정에서 큰 에러를 발견했습니다.

비디오에 사용될 컴포넌트를 개발하는데 막상 라이브에 올리고 나니, 건드리지도 않은 부분에서 에러가 발견된 것입니다.

또한 이게 비디오 컴포넌트 때문인지, 요 근래 새로 도입한 모듈 때문인지 혹은 쿠키 때문인지 정말 아무도 몰랐습니다.

이때 다행히 미리 작업된 테스트 코드가 있었고, 이를 통해 문제를 파악하고 고칠 수 있었습니다.

만약 테스트 코드 없이 눈으로만 확인하고 대충 라이브에 올렸다면, 그리고 이 문제가 1주일 뒤 혹은 1달 뒤에 발견되었다면??

이 에러를 찾느라 얼마나 고생하게 될지 정말 생각하기도 싫습니다.

 

이처럼 테스트 코드를 작성하는 것은 참 귀찮지만, 언제나 양질의 서비스를 고객에게 제공하기 위해서 혹은 항상 일정한 퀄리티의 서비스를 추 구하기 위해서 테스트는 꼭 이루어져야 할 것입니다.

그리고 앞서 언급했듯이, 빠른 시일 내에 jest.js의 예시 코드를 작성하여 게시글을 작성해보도록 하겠습니다.

 

오늘도 고생 많으셨고, 남은 하루도 알차게 보내시기 바랍니다.

 

완벽한 준비란 없다, 완벽한 준비란 영원히 시작하지 않는 것과 같다.

Es gibt keine perfekte Vorbereitung.
Perfekte Vorbereitung ist das Gleiche, wie nie anzufangen.