예전에 일하고 싶은 이상적인 환경을 생각할 때 자유롭게 마음껏 테스트할 수 있는 환경을 꼽은 적이 있다. 타겟 시스템이 쉽게 접근할 수 없는 곳에 있거나 우리 회사에 있어도 마음껏 혼자 물려 볼 수 없는 경우가 많아서 답답해서 그랬던 것 같다.만약 그때 내가 의존 대상

박미정님의 인터뷰 영상을 들으며 출근을 했다. 여러번 이직을 하시며 퇴사를 결심하게 되는 이유를 설명해 주신 부분이 공감이 되었다. 운전중이라 메모를 못했지만 합리적인 의사결정이 결여되어 있거나 과정에 대한 공유가 없는 경우 시킨 일을 하는 기계 같은 느낌을 받아서 어

아, 변경될 수 있는 외부 의존성 관련 코드를 직접 사용하는 대신 추상화 계층을 통해 접근하면 미래의 변경에 내 코드는 영향을 받지 않을 수 있고 테스트도 쉽게 할 수 있구나! 목 프레임워크 사용 대신 테스트 시에 다른 빈이 주입되도록 하는 방법도 있구나!스프링

MockBean을 활용해 서비스 코드의 변경 없이 의존객체의 동작을 쉽게 고정할 수 있어서 좋았습니다. 그러나 설계를 개선해 MockBean을 없애는게 더 나은 방법이었습니다.

프로젝트가 끝날 때까지 메시지가 추가되지 않을 것 같다면 if-else 체인으로 그냥 처리해도 될 것 같다. 좋은 디자인 패턴을 먼저 적용하려고 하기 보다 테스트를 통과하는 코드를 빠르게 작성하고 코드를 점진적으로 개선해 나가는게 더 도움이 된다. 어제 읽기모임을 통해

외부 시스템으로 전송하는 메시지는 값을 조회하는 쿼리(Query)와 값을 변경하는 명령(Command)으로 구분된다. 쿼리와 명령 메시지를 처리하는 모듈의 단위 테스트를 위해서는 외부 시스템을 모의하는 프로그램을 내장(Embedded)하고 테스트를 진행한다. 명령 전송

TDD(Test Driven Development)를 사용하면 실패하는 테스트 코드를 먼저 작성하고 테스트를 성공하는데 필요한 코드에 집중함으로 꼭 필요한 코드만 만들게 되는 효과를 볼 수 있다. 비슷하게 우리가 어떤 부분적인 스펙을 구현하기 위해 서로 의존관계를 가지

기존에 WEB에서 API 서버를 거쳐 외부 시스템까지 전달되는 경로에 모두 외부 시스템에서 정의한 메시지 ID와 의존적인 메시지 구조를 사용했다. 이유는 변환과정이 필요 없어서 간단했기 때문이다. 그러나 외부 시스템 통신 인터페이스에 변화가 생기면 WEB까지 수정되어야

지난주 TDD로 기능 하나를 개발하면서 약간의 어려움을 겪었다. 대게 기능 내부를 블랙박스로 두고 외부 인터페이스만 테스트하는 테스트 코드를 먼저 작성했었는데 기능을 구성하는 내부 모듈들이 생각보다 많고 크기가 커서 테스트를 돌리지 못하고 코드를 작성하는 시간이 점점

토비의 스프링 책 2장은 왜 테스트 코드를 작성해야하는지 설명하는데 좋은 레퍼런스가 되는 것 같습니다.테스트코드가 때때로 문서화가 되기도 해서 좋습니다.JUnit 테스트 메서드는 default 접근제어자면 충분합니다.의존하는게 많아지면 테스트가 어려워집니다. 테스트가

테스트 코드를 만들어야 스프링이 지원하는 가치를 누릴 수 있다. 테스트 코드가 없었다면 지금의 스프링 자신도 없었을 것이다.테스트 코드는 개발자의 행복과 관련이 있다. 테스트 코드는 내가 만든 코드를 확신할 수 있게 하고, 마음에 안정감을 준다. 테스트 코드는 변화(코

토비의 스프링을 읽고 배우고 느낀점을 정리합니다.지난 시간에 DI를 인터페이스를 통해 받아야 한다는 내용을 설명해 주시면서 그게 그렇게 어려운 일이 아니며 습관이 되게 하는 것이 중요하다는 이야기를 해주셔서 인상 깊었습니다. 2장을 읽으며 학습 테스트, 버그 테스트 같

내가 씻고 있을 때 종종 아이들이 화장실에 들어와 볼일을 보곤하는데 자주 나가면서 불을 끈다. 그러고 "아 미안 아빠" 하며 똑같은 실수를 반복하곤 한다. 이런게 습관인가 하는 생각이 든다.토비의 스프링 2장 테스트 부분의 말미에 학습 테스트와 버그 테스트라는 개념이

빠르고, 포괄적이고, 일관성있는 테스트 토비의 스프링 2장 테스트 부분을 읽고 있다. 테스트와 관련해 흐릿하게 알고 있던 것 위에 명쾌한 선을 그어주는 느낌을 받는다. 토비의 스프링 책은 정말 두꺼워서 펼치기 까지 많은 망설임을 주었던 것 같다. 하지만 막상 책을 한

기존에 하드웨어 API 서버에서 해주던 위성 추적 동작을 직접 구현할려니 막히는 부분이 있다. 특히 2축이 함께 움직이면서 어떤 지점을 가리키게 되는데 안테나 고각은 180도 범위인데 생성된 추적 데이터는 90도 범위라 머리속에 그림이 잘 안그려 진다. 고각에서는 간단

런타임 서버를 제한하는 기능을 PR하고 리뷰를 받았다. 나는 지역을 인식해서 고객 소유 지상국에서만 체크를 하도록 했는데(고객용 코드를 나누고 싶지 않아) 지역을 고객이 임의로 바꿀 수 있다는 문제제기를 해주셔서 방어 정책을 추가해 보았다. 리뷰의 힘을 느낀 하루.다른

아래의 LINE 엔지니어링 블로그 글을 읽고 정리합니다.

REST API로 서버를 개발하는 백엔드 개발자가 나에게 아래와 같이 자랑스럽게 말했다. "JUnit으로 API 테스트 다 했으니까 사용자 테스트는 하지 않아도 되요"

오늘은 테스트 시나리오를 작성하는 기본 개념에 대해 정리해 보려고 한다.먼저 아래와 같은 요구사항이 있다고 하자.요구사항 1- 현재 컴퓨터의 CPU 사용량을 화면에 표시해야 한다. 위 요구사항에 대한 테스트 시나리오를 누군가 작성해 보자. 프로그램 메인화면에서 시스템

생애 첫 Spring 프로젝트! 그리고 JUnit! JUnit으로 단위 테스트를 작성하는데 @BeforeAll 어노테이션이 static 함수에만 적용이 된다. 인스턴스 함수에 적용해서 테스트 케이스에 해당하는 액션이 아닌 공통된 준비 단계들, 예를 들면 TCP 서버와