xUnit4 단언문 (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. 검증부 (assert / expect)는 하드코딩한다 최근 코드리뷰를 하다가 자주 지적하던 내용이 있어, 정리하게 되었다. 요즘 팀 분들이 가장 많이 하는 실수가 바로 검증부에 도메인 로직이 추가되는 것이다. 이를테면 다음과 같은 구현 클래스가 있다고 해보자. export class FilePath { private readonly _path1: string; private readonly _path2: string; private readonly _path3: string; private readonly _path4: string; constructor(path1: string, path2: string, path3: string, path4: string) { this._path1 = path1; this._path2 = path2; this._path.. 2021. 11. 15. 테스트 코드에서 내부 구현 검증 피하기 테스트 코드를 작성하고 운영하다보면 기존 코드가 조금만 변경되어도 테스트를 다 고쳐야하는 경우가 종종 있다. (모든 경우가 그렇진 않겠지만) 기능의 최종 결과를 검증하는게 아니라 내부 구현을 검증하는 경우에 자주 이런일이 있었다. 내부 구현을 검증하는 테스트들은 구현을 조금만 변경해도 테스트가 깨질 가능성이 커진다. 내부 구현은 언제든지 바뀔 수 있기 때문에 테스트 코드는 내부 구현 보다 최종 결과를 검증해야한다. 그럼, 내부 구현을 검증하는 경우란 어떤 것인지 알아보자. 1. 상세 구현부를 다 검증하는 경우 이를 테면 다음과 같이 합계 금액을 구하는 클래스가 있다고 하자. export class OrderAmountSum { minusSum: number = 0; plusSum: number = 0; .. 2021. 11. 11. JUnit 만들어보기 안녕하세요? 이번 시간엔 JUnit을 직접 만들어보는 시간을 가지려고 합니다. 모든 코드는 Github에 있기 때문에 함께 보시면 더 이해하기 쉬우실 것 같습니다. (공부한 내용을 정리하는 Github와 세미나+책 후기를 정리하는 Github, 이 모든 내용을 담고 있는 블로그가 있습니다. ) 계기 긴 추석연휴 기간동안 미뤄둔 포스팅 예정 글들을 정리했습니다. 3개를 연달아 처리하고 뭐가 더 남았나 에버노트를 보다가 아주 예전에 메모해놓은 일감이 있었습니다. 바로 나만의 XUnit 만들기입니다. 토비님께서 올리신 글을 보고 일감 등록을 했었던 기억이 떠올랐습니다. (원분 : 페이스북링크) 일단 회사에서 사용하는 기술들을 익히기에 급급해 계속 미루다가 이제야 다시 봤습니다. 장기간 휴식이 또 언제 생길지 .. 2017. 10. 7. 이전 1 다음
