[Javascript] - Testing

Testing (테스팅)

 

- 프로그램이 완벽하다고 검증할 수 있는 테스트는 없습니다.

 

프로그램에 결함이 있다고 증명할 수는 있지만, 프로그램에 결함이 없다고 증명할 수는 없습니다.

테스트가 실패하는 것은 테스트 자체가 프로그램이 올바르다는 것을 증명하려고 만들어졌기 때문입니다.

 

- 버그

 

프로그램의 버그는 대부분 사람에 의해 만들어집니다.

프로그램에서 혼란이 발생할 만한 부분은 최대한 없어야 합니다.

버그는 혼란의 또 다른 말로, 혼란을 없애는 것이 테스트하는 것보다 훨씬 더 생산적입니다.

그렇게 하기 위해 프로그램을 최대한 단순 명료하게 만들어야 합니다.

 

- 소프트웨어의 비대함

 

비대함이라는 것은, 프로그램이 그냥 크기만 한 것입니다.

규칙 없이 기능을 마구 추가하거나, 잘못된 구조로 인해 비대해질 수 있습니다.

또한 다른 많은 라이브러리나 플랫폼, 패키지와 강하게 결합된 라이브러리들, 플랫폼들, 패키지들에 의존하다보니 더욱 비대해집니다.

 

비대함은 애자일 개발론의 사이드 이펙트이기도 합니다.

비대함을 관리하기 위해 개발팀이 커지기도 하지만, 더 큰 팀은 더 큰 비대함을 초래합니다.

 

프로그램이 비대해지면 버그에 취약해지고, 적절한 테스트를 하기도 힘듭니다.

 

게으른 로딩 (lazy loading : 라이브러리나 함수를 실제 사용하는 시점에 적재하는 것), 나무 흔들기 (tree shakers : 실행되지 않는 코드들 제거) 는 필요 없는 코드를 지연시키거나 제거하는 방법으로 알려져 있지만, 이로 인해 코드가 더 비대해지는 결과가 따라옵니다.

 

- 비대해지지 않으려면..

 

처음부터 비대하지 않게 만들어야 합니다. 설계와 개발에서 소프트웨어의 단순함을 최우선으로 삼아야 합니다.

소프트웨어를 비대하게 만들 수 있는 툴이나 패키지는 사용하지 말아야 합니다.

개발 사이클의 일부를 불필요한 코드와 문제 있는 패키지 제거에 할당해야 합니다.

 

기능은 장점도 있지만 비용도 들며, 비용을 지불하는 데 실패하면 대가는 비대함 입니다.

 

- 테스트 주도 개발 (TDD)

 

일부 TDD 광신도들은 엉성하고 에러가 많은 코드라 할지라도 TDD 에서는 허용된다고 합니다.

아마 테스트로 모든 버그를 찾을 수 있다고 가정하기 때문인 것 같습니다.

 

테스트에만 의존해서는 모든 버그를 찾을 수 없습니다. 

 

단위 테스트는 저수준 코드에서는 아주 효과적이지만, 고수준으로 올라갈수록 효과가 작습니다.

의존성이 증가하면서 테스트가 점점 의미 없어지기 때문입니다. (테스트를 만드는 비용은 목업, 가짜 코드를 만드느라 점점 증가합니다)

 

순수함이 줄어들면 버그가 증가하지만 단위 테스트는 순수함을 테스트하지는 않습니다.

모듈화가 충분하지 않다면 버그 역시 많겠지만 단위 테스트는 모듈화 정도를 테스트하지 않습니다.

단위 테스트는 비대함을 검사하지 않고, 여러 한계로 인해 가짜 코드와 목업 코드를 테스트합니다.

그렇다고 단위 테스트가 나쁘다는 것은 아닙니다.

 

- 테스트는 필요하며, 효과적으로 테스트해야 하고 반드시 해야합니다.

 

- assertEquals("add 3 + 4", 7, add(3, 4));

 

대부분의 테스트 라이브러리는 위와 같은 호출을 비슷한 형태로 지원합니다.

이 테스트는 단 한 번의 더하기 테스트입니다. 아주 많은 범위의 수에 대한 아주 많은 테스트가 필요할 것이지만, 다 만들기엔 리소스 낭비가 큽니다. 또한 이런 형태의 테스트는 비동기가 아닌 순차적 함수만 테스트할 수 있습니다.

 

- JSCheck, Mocha, Jest, Jasmine, ...

 

테스트 케이스에 대해 아주 많은 수의 임의의 시도를 자동으로 생성해내고, 비동기 프로그래밍도 지원하는 JSCheck 라는 라이브러리에 대해 이 책에서는 얘기하고 있습니다.

하지만 적어도 지금까지 개발을 해오며 이 라이브러리를 통해 테스트하는 코드를 보지 못했고, 비슷해보이는 JSVerify 도 마찬가지입니다.

(제가 모르는 것일수도 있습니다..)

 

이미 예전부터 Mocha, Jest, Jasmine, Karma 등의 프레임워크를 통해 자바스크립트 프로그램을 테스트하고 있었습니다.

최대한 테스트 케이스, 스펙 코드를 만들려고 해왔지만 이것이 정말 효과적인 테스트였는지는 다시 한 번 생각해봐야 할 것 같습니다.

적어도 그간 테스트에서, "테스트 케이스에 대해 아주 많은 수의 임의의 시도를 자동으로 생성" 해서 테스트하는 부분은 없었던 것 같습니다.

 

이러한 부분들에 대해선 좀 더 찾아보고 확인 후 TDD 에 대해 따로 포스팅해보도록 하겠습니다.

 

출처 : 자바스크립트는 왜 그 모양일까?