비동기적으로 동작하는 코드를 테스트 하기 위해서는 시간이라는 변수를 다룰 수 있어야 합니다. 크게 아래 3가지 범주의 요구가 있습니다.

이 글을 읽어서 좋습니다.

최근 몇 년 간 비동기 시스템에서 코드를 작성하고 테스트하는 일이 많아졌습니다. 어느 날 테스트 코드를 작성하고 있는데 테스트 코드에서 비지니스 로직을 표현하는 코드 보다 비동기적인 처리를 위한 기술적인 코드들이 더 많은 것이 눈에 띄었습니다. 다음 예제 코드는 상점에

서비스 추상화와 목(Mockito) 프레임워크 활용

Java의 대표적인 Mock 프레임워크인 Mockito에서 제공하는 핵심 기능들에 대한 학습테스트 코드를 작성합니다. 우선 테스트를 위해 테스트 대상 클래스(TestTarget)와 목킹 대상이 될 협력 클래스(Collaborator) 그리고 둘 간에 주고 받을 메시지

테스트의 일관성과 속도 두 마리 토끼 잡기

애노테이션은 정의하기에 따라서 타입, 필드, 메서드, 파라미터, 생성자, 로컬 변수의 한 군데 이상 적용 가능하다.애노테이션이 부여된 클래스의 패키지, 클래스 이름, 접근 제한자, 상속한 클래스나 구현 인테페이스가 무엇인지 알 수 있다.애노테이션 같은 메타정보를 활용하

토비의 스프링 6장 AOP를 읽고 더 나은 설계 및 테스트를 위한 내용을 별도로 정리합니다. 스프링의 ProxyFactoryBean의 설계를 보면서 기술적인 영역에서도 변하는 것과 변하지 않는 것을 구분하면 재사용성을 높일 수 있고 최소한의 노력으로 변경에 대처할 수

신규 안테나의 제약사항 때문에 미션을 수행할 수 없는 구간이 생기는 문제가 있었다. 하드웨어 엔지니어로부터 미션이 안되는 구간을 감안하고 운영하겠다는 이해할 수 없는 대답을 듣고 마음이 어려웠던 기억이 난다. 그 날 회고를 하면서 나 스스로 문제를 해결하겠다는 마인드를

최근에 배운 동등분할과 경계값 테스트라는 개념을 현업에 적용해 보았다. 동등분할이란, 동일한 결과를 내는 입력들을 하나의 그룹으로 묶어서 입력 그룹의 대표 값을 정해 테스트하는 것을 의미한다. 경계값 테스트를 이어서 적용하면 동등분할로 구분된 각 입력 그룹에서 경계에

요즘 토비의 스프링 책에서 배운 내용들이 내 업무 현장에서 춤을 추는 것 같다. 오늘 안테나의 위성 추적 경로를 최적화 하기 위한 간단한 알고리즘을 설계하고 구현하는 작업을 했다. 테스트 방법을 고민하다 지난주 토비의 스프링 책에서 읽었던 ‘단위 테스트 고립하기’라는

토비의 스프링 5장 서비스 추상화를 읽고 테스트와 관련된 내용을 별도로 정리합니다.최근에 테스트 대역이라는 용어를 처음 접했다. 여기서 사용된 '대역'이라는 용어의 뜻은 '배우가 맡은 역할을 사정상 할 수 없을 때에 다른 사람이 그 역할을 대신 맡아 하는 일. 또는 그

객체지향적인 코드는 다른 오브젝트의 데이터를 가져와서 작업하는 대신 데이터를 갖고 있는 다른 오브젝트에게 작업을 요청한다. 오브젝트에게 데이터를 요구하지 말고 작업을 요청하라는 것이 객체지향 프로그래밍의 가장 기본이 되는 원리이기도 하다. 테스트 코드와 애플리케이션 코

다루고 있는 코드의 덩치가 커지면 문제의 원인을 찾는게 어려워 진다. 문제와 관련있을 법한 코드를 내 머리에 담지 못한다. 들어가지를 않아 아무것도 담지 못했으니 무엇 부터 손대야 될지 모르겠는 막막한 상태에 놓이곤 한다. 결국 내 머리에 담을 만한 단위로 나누어 내지

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