코드 리뷰를 하다보면 약간 복잡한 expression 혹은 statement의 결과를 변수로 치환한 다음에 아래에서는 그 변수를 사용하는 경우가 있다. 변수의 값 참조가 여러번 이뤄지면 문제가 아니지만 갸우뚱하게 되는 케이스는 한번만 사용하는 경우다. 대부분의 자동화 분석 도구는 이런 경우에 대해 고치라는 처방전을 준다. 하지만 나는 기계가 아니라 사람이고 사람이 보기에 복잡해보이는 걸 두는 것보다는 “변수가 의미를 설명해주는데 …
기본적인 내용은 Spring 블로그에 포스팅된 내용을 바탕으로 한다. 한글로 읽기 귀찮다면 링크된 본문을 참고하자!! 스프링 부트는 복잡한 설정없이 손쉽게 웹 어플리케이션 서버를 실행할 수 있다는 점때문에 자바 언어 세계에서 널리 사용되어오고 있다. 부트 역시 스프링 프레임워크에서 지원했던 방식과 유사한 형식의 테스트 방식을 지원하고 있었다. 하지만 부트의 테스트는 부트 자체가 웹 어플리케이션 개발을 쉽게 …
Continue reading ‘SpringBoot 1.4 기반의 Integration Test 작성하기’ »
JUnit에서 조건값을 바꿔가면서 테스트를 해야하는 경우에 이 방법을 사용하는게 테스트 비용을 아끼는데 좋다. 예제에서는 테스트를 위한 입력으로 PrimeNumberValidationInput이라는 클래스를 사용했다. 다른 책에서 예제를 인용할 때는 보통 Object[][]을 이용하는 경우가 많던데, 물론 간단한 수치 입력을 하는 경우에는 이 방법을 사용해도 크게 나쁘지는 않은 것 같다. 하지만 Object 변수를 사용한다는게 뭔가 테스트 코드의 품질을 떨어트리는 것만 같은 …
Continue reading ‘JUnit Parameterized Test – 반복 테스트를 하는 뻔한 방법’ »
CI 들어봤나? Continuous Integration의 약자이다. 해석하자면 “지속적으로 통합하라” 라는 이야기다. 뭘? 코드를. 누가 작성한 코드를? 여러분과 여러분들의 동료들이 작성한 코드를 말한다. 왜 통합을 해야할까? 이유는 간단하다. 통합을 위해서. 뭔 소리냐구? 통합을 지속적으로 시도하는 이유는 바로 필요한 시점에 사고 터지는 걸 막기 위해서다. 누구나 익히 알고 있듯이 모든 개발은 팀 작업이다. 혼자 잘해서 되는 개발은 더 …
사람들과 전화너머로 이야기를 하다보면 TDD를 자신있게 말하는 분들을 종종 만난다. 물론 이 분들의 이력서에도 “활용 가능한 기술”들 가운데 하나로 TDD라는 3글짜 알파벳이 강렬하게 적혀있다. 개인적으로 TDD 방식의 개발의 예찬론자이기도 하기 때문에 이런 분들을 만날 때마다 반가운 생각이 든다. 처음 이 단어를 들었던 때가 아마도 2010년도 쯤이었을 것 같다. 주변의 개발자들 가운데 아는 사람도 적고 해서 …