간만에 개발에 대한 글을 써본다. 코드를 잠깐 봐볼까 싶다가 @VisibleForTesting이라는 Annotation을 봤다. 사실 처음보는 Annotation이라 뭐하는 놈인가 싶은 생각이 들어서 찾아봤다. Package com.google.common.annotations Annotation Type VisibleForTesting @GwtCompatible public @interface VisibleForTesting Annotates a program element that exists, or is more widely visible than otherwise necessary, only for use in test code.Do not use this interface for public …
Coding을 하면서 많은 것들을 고민하지만, 테스트만큼 고민스러운 것도 없다. 논리적으로 도움되고, 유지보수를 위해서라도 반드시 필요하다. 하지만 빨리 만들어서, 고쳐서 내보내야 한다는 심리적인 압박감이 강해지다보니 넘어가자. 바쁜데… 라는 합리성을 부여해버린다. 그래놓고 장애나면 급 후회를 하긴 하지. 언제나 그렇지만, 코딩/개발 단계의 시간보다 장애 대응하면서 보내는 시간이 훨씬 길다. 개발자의 입장에서 테스트는 반드시 필요하니 꼭 작성해두길 바란다. 한번 쓰고 …
Spring framework에서도 5.X 버전부터 Reactive 방식의 프로그래밍이 가능하다. 이게 한 1년 이상 전 이야기인 것 같다. 내 입장에서 좋기는 한데 이게 그림의 떡이었다. 대부분의 Java Backend 개발을 Springboot framework을 가지고 하고 있는데, 여기에 Spring framework만 5.X 버전으로 덜렁 넣을 수 없기 때문이다. Spring 5.X 버전을 지원하기 위해 2.X 버전이 개발중에 있었지만, Milestone 버전이었고, 옆에서 Early …
Continue reading ‘Spring 5 reactive programming ground zero’ »
코드 리뷰를 하다보면 약간 복잡한 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년도 쯤이었을 것 같다. 주변의 개발자들 가운데 아는 사람도 적고 해서 …