테스트코드25 SonarLint와 SonarCloud 연동하기 (WebStorm Plugin) 지난 시간에 프로젝트와 SonarCloud 연동을 했습니다. 이번 시간에는 프로젝트와 연결된 SonarCloud를 개발환경인 WebStorm의 SonarLint 플러그인과 연동해서 IDE로 개발 중에도 SonarCloud 검증이 되도록 설정해보겠습니다. 1. 설정 먼저 SonarLint 플러그인을 설치합니다. 설치된 SonarLint 플러그인의 설정을 열어봅니다. 아래와 같이 Action 검색 (CMD + Shift + A) 을 통해 검색합니다. 다음과 같이 커넥션 연결 화면이 나온다면 Configure the connection 을 선택합니다. SonarQube / SonarCloud connections의 + 버튼을 클리해서 새로운 커넥션을 추가합니다. 여기서는 SonarCloud를 쓰고 있으니 So.. 2022. 4. 14. expect에서 false와 falsy 구분하기 Jest로 테스트 코드를 작성하다보면 습관적으로 IDE의 자동완성으로 toBeFalsy 와 toBeTruthy 를 사용하곤 했다. 저 둘이 아닌 toBe(false) 와 toBe(true) 는 한 번의 자동완성으로 안되기 때문에 굳이 사용하진 않았다. 그러다 팀 분의 의견을 받고 더이상 toBeFalsy() 는 사용하진 않고 있다. 물론 이에 맞는 쓰임새가 있겠지만, 모든 결과를 강타입으로 처리하는걸 선호하는 입장에서는 toBeFalsy() 는 선호하기가 어렵다. 다음과 같은 이유 때문이다. toBeFalsy() 는 JS에서 false로 판단되는 모든 값들을 기준으로 한다 내가 의도한것은 boolean 타입의 false 를 원했지만, 수행 결과가 0, undefined, null, '' 이면 toBeFa.. 2022. 4. 13. 단언문 (expect/assert) 안에서 비교하지 않기 간혹 코드를 보면 expect 에서 비교를 하는 코드를 보곤 한다. 이를테면 다음과 같은 경우이다. it('getCount의 결과는 5보다 크다', () => { const result = getCount(); expect(result > 5).toBe(true); }); 당장 봐서는 문제가 없어보인다. 오히려 비교값이 더 큰지 검증하는 jest 함수를 별도로 찾아보지 않아도 된다는 장점도 있어보인다. 비슷한 예제로 다음과 같은 코드도 종종 보게 된다. it('getCount의 값은 10과 동일하다', () => { const count = getCount(); expect(count === 10).toBe(true); }); 하지만 이 테스트 코드들은 크게 2개의 단점을 갖고 있다. (정확히는 잘못된 .. 2022. 4. 10. SonarCloud를 통한 Node.js & Jest 프로젝트 정적 분석하기 일반적으로 프로젝트의 코드 퀄리티를 올리기 위해서는 단위 테스트를 비롯해 여러가지 장치를 도입한다. 이때 가장 가성비가 좋은 작업이 정적 코드 분석을 도입하는 것이다. 정적 코드 분석은 코드내에서 발견할 수 있는 코드 스멜, 잠재적인 결함, 컨벤션 체크, 보안 취약점 등을 코드 레벨에서 분석해서 레포팅 해준다. 이런 정적 코드 분석 도구에는 여러가지가 있지만, 가장 많은 사용자들이 사용하는 도구는 SonarQube(소나큐브) 이다. 기존에는 설치형외에는 지원하지 않았지만, 최근에는 SaaS 형태로 SonarCloud 가 출시되었다. Github에 공개된 저장소에 한해서는 소나 클라우드의 전체 기능을 무료로 사용할 수 있다. 그래서 개인 프로젝트는 SonarCloud로 편하게 연동하고, 무료로 정적 코드 .. 2022. 4. 5. Jest로 Error 검증시 catch 보다는 expect Jest를 통한 테스트를 작성하다보면 Exception에 대한 검증을 작성해야할 때가 있다. 이럴때 보통 2가지 방법 중 하나를 선택한다. try ~ catch expect.rejects.toThrowError 실제 코드로는 다음과 같다. // try ~ catch it("[try/catch] 주문금액이 -이면 BadParameter Exception 을 던진다.", async () => { try { await acceptOrder({amount: -1000}); } catch (e) { expect(e).toBeInstanceOf(BadParameterException); expect(e.message).toBe('승인 요청 주문의 금액은 -가 될 수 없습니다'); } }); // expect it(.. 2022. 3. 18. 테스트코드에서 Optional chaining(?.) 쓰지않기 여러 포스팅에서 언급한것처럼 테스트 코드는 빠르게 실패를 파악할 수 있어야 한다. 그런면에서 Optional chaining(?.) 은 테스트코드에 적합하지 않다. MDN의 설명을 가져오면 Optional chaining(?.)은 체이닝 연산자(.) 와 유사하게 작동하지만, 만약 참조가 nullish (null 또는 undefined)이라면, 에러가 발생하는 것 대신에 표현식의 리턴 값을 undefined로 반환한다. 따라서 참조가 누락될 가능성이 있는 경우 연결된 속성으로 접근할 때 더 짧고 간단한 표현식이 생성된다. 어떤 속성이 필요한지에 대한 보증이 확실하지 않는 경우 객체의 내용을 탐색하는 동안 도움이 될 수 있다. 안정적으로 객체 탐색이 가능하기 때문에 프로덕션 코드에서는 적극적으로 사용하는 편.. 2022. 3. 8. 이전 1 2 3 4 5 다음