모든 테스트는 독립적이어야 한다. V
서로 다른 테스트가 종속되지 않아야 하나의 테스트가 실패하더라도 다른 테스트가 영향을 받지 않는다.
테스트는 Atomic한 속성(모두 성공 / 실패)을 따라야하며 중간에 실패를 하는경우가 있으면 안된다.
또한 테스트중인 데이터는 모든 테스트마다 분리하여 적용하지 않으면 테스트를 사용하는 전체적인 결과의 싱크를 보장할 수 없다.
-> 유저의 행동에 초점을 맞춰서 테스트를 설계하고 테스트하며 모든 사건에 대해서 독립적으로 다룬다. 각 테스트 별로 인과관계가 있지 않으며 모듈테스트시 필요한 작업들은 before / after 시점에서 하도록 한다.
테스트 이름에 3가지를 포함해야 한다. V
- 무엇을 테스트하고 있는지?
- 어떤 상황과 시나리오인지?
- 예상되는 결과는 무엇인지?
-> 모듈 / 기능별 테스트를 작성하며 어떤 상황에서 어떤 시나리오로 전개되는지 명확히 작성하고 기대되는 결과를 반드시 적는다.
Assetion을 사용해야 한다. V
Assertion은 프로그래밍시 테스트에 사용되며 테스트를 보기 쉽게 설계하고 참과 거짓으로 결과를 알려준다.
예를들어 expect('age').to.be.equel('32')의 경우 변수의 연령에 따라 32와 같은지 아닌지 참/거짓의 결과를 알 수 있다.
일반적인 테스트 보다 코드라인의 설명이 쉬워서 테스트에 사용하기 용이하고 결과 또한 테스트 설계시 어떤 값을 예상하는지에 대해 명확하게 설계하기 때문에 일반적인 테스트와 같이 결과값에 대해 해석할 필요없이 참/거짓 값으로 테스트의 성공 유무를 알 수 있다.
-> chai를 사용. Should, Expect, Assert 등의 Assertion 모듈을 사용한다. 이는 chain문법이 사용 가능 하므로 읽기 쉽고 표현이 자유로우므로 BDD스타일의 테스트를 설계하는데 이점이 있다. ex) expect.(jake).to.have.property('develoiper');
테스트 러너 사용 V
테스트 러너는 테스트파일을 읽어들어 작성한 코드를 실행하고 결과를 콘솔 또는 로그로 출력해준다. 또 구현코드가 변경될시에 테스트를 재실해주는 Watcher의 기능도 제공한다. 테스트러너가 있으면 설정한 데이터베이스값( dummy/real )으로 테스트를 실행할 수 있다.
-> Mocha를 사용한다. 최초의 테스트도입으로 Mocha, Jest, Jasmine 이 셋 중에 고민이 있었다.
| Mocha | Jest | Jasmine |
|
|
모두 허용합니다.
|
Mocha가 라이브러리, 유틸리티 설정에 있어 어려울 수 있는 단점과, atomic test까지 지원하지 않지만 휴먼스케이프의 프로그램 특성상 전산상의 장애가 엄청나게 치명적인 결과를 일으키지 않는다는 판단과 라이브러리선택과 유틸리티 설정의 경우 그리 단점이 될것 같지 않아서 Mocha를 선택 하였다.
테스트 커버리지에 초점 X
테스트커버리지를 잘 예상해야 한다. 테스트를 반드시 해야 하는지, 아닌지 판단을 해야 한다. 테스트에 들어간는 공수 또한 비용으로 책정되기때문에 테스트전 이를 잘 판단해보고 테스트를 진행해야 한다. 커버리지를 잘 판단하고 효율적으로 운용해야 한다.
-> 커버리지 설정에 고려해야 한다.
테스트 커버리지 플러그인 사용 X
테스트 범위를 테스트하는 플러그인 사용할 수 있다. 플러그인은 테스트를 분석하고 테스트를 건너뛰었는지 여부를 알려준다. 모든 테스트 사례가 적용되었는지, 작성된 코드에 테스트가 적용되었는지 백분율을 알 수 있다.
-> 이스탄불 사용 예정.
테스트 커버리지 레포트 분석 X
테스트 커버리지를 분석하고 실패한 테스트의 이유를 분석하고 문제가 있는지 확인한다.
-> 이스탄불 사용 예정.
Mutation Testing X
Mutation testing은 테스트의 조건을 수정하여 의도적으로 fail시키거나 fail의 경우 테스트를 통과시켜 코드내에 존재할 수 있는 애매모호한 부분을 찾는다. stryker와 같은 모듈을 사용하는것을 추천한다.
-> 도입생각 없음.
테스트로 표절 확인 X
코드상에서 표절을 항상 확인해야 한다. 작업자가 인터넷에서 코드를 복사하여 동작시키는것은 흔히 있는 일이며 이는 라이센스상의 문제를 일으킬 수 있다. 이를 해결하기 위하여 plagiarism-checker 를 사용할 수 있다.
-> 라이센스 문제가 있을 수 있으니 도입 예정.
Property 기반 테스트 X
property 기반테스트는 엔터티의 property를 확인하기 위해 사용된다. 예를들어 input a, b가 있을때 b가 항상 짝수property를 가지는지 여부를 확인한다. 속성기반 테스트는 검사해야할 항목이 특정되어 있을때 함수의 임계값을 매우 쉽게 얻을 수 있으므로 예측가능한 장점이 있다.
-> Property 기반인것도 있고 아닌것도 있다.
Chai 라이브러리 사용 V
Assertion라이브러리를 사용하여 테스트코드를 보기쉽게 작성한다.
-> supertest (http 관련 모듈) + chai 사용중이다.
예외적인 시나리오 확인 X
예외적으로 일어나는 상황에 대해서 확인해야 한다. 일어날 수 있는 상황을 만들어서 응용프로그램이 어떻게 동작하는지 확인하고 어떤값이 반환되는지 알수 있어야 한다.
-> 시스템 전반적인 부분에 대해서 아키텍처를 보고 업무와 연관지어 예외적인 시나리오를 설계할 수 있어야 한다.
테스트 피라미드 X
테스트는 단위테스트(독립적인 단위모듈) -> 통합테스트(모듈을 결합하여 테스트) -> 사용자 인터페이스 테스트(Selenium)를 수행한다.
컴포넌트 테스트 X
모든 테스트 계획을 컴포넌트 모듈별로 나누어서 테스트한다. 단위테스트후에 컴포넌트테스트를 수행하며 컴포넌트 테스트는
단위 테스트보다 큰 범위와 빠른속도를 가진다.
-> 단위테스트로 구성한 후에 도입 고려.
인프라문제에 대한 고려 X
테스터들은 보통 코드레벨에서의 테스트만 고려하여 인프라에서 발생하는 문제들을 놓치는 경우가 있다.
인프라에 대해서 테스트를 수행하고 피드백 보고서를 분석해야 한다.
-> 예외적인 시나리오와 동일.
dependency 업데이트 자동화 X
테스트를 수행하기 위해서는 많은 라이브러리와 도구가 필요하다. 종속성이 오래된경우 테스트수행을 올바르게 수행하지 못할 수 있으므로 종속성에 대한 업데이트가 필요하다. 이러한 문제는 업데이트를 자동화하여 해결할 수 있다.
-> 적용해야한다.
Lint를 해라. V
ESLint와 같은 Lint플러그인은 코드 작성시에 오류, 문법을 검사하기 위해 제작되어있다.
Lint는 테스트시에 잘못 작성된 문법들을 catch하는데 도움을 주기 때문에 test시 같이 사용하면 좋다.
-> eslint 5.6.0 사용중 + prettier 적용해야함.
병렬화 X
테스트를 병렬처리 하게 되면 피드백 루프에 대한 범위를 줄일 수 있고 이는 테스트시간을 줄일 수 있으므로 리소스 절약에도 도움이 된다.
-> isolate만 고려 병렬화에 대한 테스트까지는 공부를 좀 더 해야함.
크로스 브라우저 테스트를 위해 온라인 셀레늄 그리드를 사용 한다. X
-> 추후에 공부하여 선택.