# stub
Mockito 사용하기
✏️ Mock 테스트 할 때 필요한 실제 객체를 흉내내는 가짜 객체를 만들어 테스트의 효율을 높히기 위해 사용한다. 서비스 로직의 부하가 많이걸려, 시간도 너무 오래걸리는 경우 서버간 통신이 제대로 되고있는지 확인해야하는 경우 요청을 보낼 API 가 작업중인 경우 등등 ... ✏️ Mock 객체의 종류 📍 Stubbing Mock 객체를 통해 반환될 미리 준비된 답변을 뜻한다. Stub 이라고도 불린다. when method 를 사용해 Stubbing 을 사용한다. when 에 stubing 할 method 를 넣고 method chaining 형식으로 사용된다. 📍 @Mock 가짜 객체를 뜻한다. 객체의 method 를 호출하려면 반드시 stubbing 을 해야한다. 만약 Stubbing 을 생략할경우 Null 또는 0 을 반환한다. 📍 @Sp
이해하기 쉬운 RPC와 Stub 설명
3.8.2 Remote Procedure Calls RPC(Remote Procedure Call)는 원격 프로시저 호출을 가능하게 해주는 프로토콜입니다. 이를 통해 클라이언트는 원격 호스트에 있는 프로시저를 마치 로컬에서 호출하는 것처럼 사용할 수 있습니다. 이러한 프로세스를 이해하기 쉽게 설명해 드리겠습니다. 먼저, stub이란 프로시저 호출을 추상화하는 작은 코드 조각입니다. RPC에서 stub은 클라이언트와 서버 사이에 원격 프로시저 호출을 처리하기 위해 사용됩니다. RPC의 작동 과정은 다음과 같습니다: 클라이언트에서 원격 프로시저를 호출하려면, 클라이언트 측에 stub이 필요합니다. 이 stub은 각각의 원격 프로시저에 대해 별도로 존재합니다. 클라이언트가 원격 프로시저를 호출하면, RPC 시스템은 해당 stub을 호출하고 원격 프로시저에 제공된 매개변수를 전달합니다. 클라이언트 측 stub은 서버의 포트를 찾아 매개변수를 정리(marshal
Mockito와 Stubbing
단위 테스트에서 Mock을 얼마나 사용해야 할까? 지난번 포스팅에서 테스트 시 외부 API 또는 DB와 통신해야할 때 테스트 환경이 구축되어있지 않아도 Mock 사용해 테스트할 수 있다고 작성하였는데, 그렇다면 얼마나 Mock을 사용해야하는지 판단해보자. 예제 이전에 작성한 예제 코드를 보면 StudyService의 createStudy 메소드에서 사용되는 모든 객체(studyRepository, memberRepository, studyMapper)들을 mocking하고 있다. 단위 테스트에서 단위를 어떻게 생각하는지에 따라 다른 테스트 코드가 작성되는데 예제 코드는 createStudy 메소드에서 사용되는 모든 객체들을 엄격하게 mocking하고 있다. 그렇다면 상황을 바꿔서 생각해보자. StudyMapper studySevice studyMapper가 인터페이스로 작성되어 있었던 이전 포스팅과 달리 위의 코드로 실제로 구현이 되어있는 상태라면 @Spy 어노
Unit Test 작성시 필요한 여러 기술 (Test double)
Unit Test 작성시 필요한 여러 기술 Test Double 이란 테스트를 진행하기 어려운 경우 이를 대신해 테스트를 진행할 수 있도록 만들어주는 객체를 의미한다. Test Double은 크게 Dummy, Fake, Stub, Spy, Mock으로 나눈다. 사진 출처) [https://subscription.packtpub.com/book/application-development/9781783983605/1/ch01lvl1sec09/understanding-test-doubles](https://subscription.packtpub.com/book/application-development/9781783983605/1/ch01lvl1sec09/understanding-test-
JUnit, Coverage
JUnit TDD(Test-driven development): 테스트 주도 개발에서 사용하지만, 코드의 유지 보수 및 운영 환경에서의 에러를 미리 방지 하기 위해서 단위 별로 검증 하는 테스트 프레임워크 단위테스트: 작성한 코드가 기대하는 대로 동작을 하는지 검증 하는 절차 JUnit: Java 기반의 단위 테스트를 위한 프레임워크 Annotation 기반으로 테스트를 지원하며, Assert를 통하여, (예상, 실제)를 통해 검증 [Mockito 사용법] 1. Mock 객체 의존성 주입 Mockito에서 Mock(가짜) 객체의 의존성 주입을 위해서는 크게 3가지 어노테이션이 사용된다. @Mock: Mock 객체를 만들어 반환해주는 어노테이션 @Spy: Stub하지 않은 메소드들은 원본 메소드 그대로 사용하는 어노테이션 @InjectMocks: @Mock 또는 @Spy로 생성된 가짜 객체를 자동으로
프로젝트 준비 12일차
유닛 테스트 어제 했던 유닛 테스트를 이어서 오늘은 mock 처리 했던 부분을 Stub 을 사용해봤다. 앞서 말하지만 mock , Stub 둘 중 어떤게 더 좋고 나쁘고 할게 아니라 상황에 따라 사용한다고 했다. mock > const ProductClient = require("./product_client"); > class ProductService { constructor() { this.productClient = new ProductClient(); } > fetchAvailableItems() { return this.productClient .fetchItems() .then((items) => items.filter((item) => item.available)); } } 전에는 이 부분을 전부 컴포넌트 , 함수 mock 처리를 통해 결과에 지장이 없고, 무시되게끔 사용했다. mo
[Onboarding] : Unit Testing
일반적으로 Mock이란 제작하기 쉬운 재료를 이용해 제품의 외양을 흉내 낸 모조품을 말한다. 소프트웨어 엔지니어링에서도 Mock이라는 단어를 비슷한 의미로 사용하는데, 예를 들어, 실제 모듈과 비슷하게 보이도록 만든 가짜 객체를 Mock 객체라고한다. 실제 객체를 만들기엔 비용과 시간이 많이 들거나 의존성 때문에 제대로 구현하기 어려울 경우, 이런 가짜 객체, 즉 Mock 객체를 만들어 사용하는 경우가 많다. Mock 객체를 이해하기 위해 아래와 같이 상황을 가정해보자. 나는 사용자 암호 변경 기능, SavePassword()를 구현하기 위해 테스트 케이스를 작성해야 한다. SavePassword() 기능을 구현하기 위해 위와 같이 TestSavePassword() 테스트 케이스를 만들었다. 그런데 SavePassword 기능 구현 시, 추가 요구 사항이 필요하다는 것을 발견했다. 사용자 암호를 반드시 암호화한 다음에 저장해야 한다는 것이다. 사용하게 될 암호화 모듈의 스펙은
하스켈에서 테스트 mocking 하기
어제는 어니언 아키텍처에 대해 적어봤다. 어니언 아키텍처는 Tagless Final이라고 하는 패턴으로 구현했다. 타입 변수로 만들어진 모나드 컨텍스트를 사용하는 곳에서 타입에 따라 결정할 수 있었다. 테스트 코드 역시 테스트를 위한 모나드 타입을 만들어 의존성의 목(Mock)이나 스텁(Stub)을 만들면 된다. 하지만 테스트 케이스마다 다른 스텁을 사용해야 한다면 어떻게 해야 할까? TestApp과 같은 타입을 여러 개 만들어야 할까? 상당히 번거로운 일이다. Clojure에는 제한된 컨텍스트에서 값의 바인딩을 바꿔서 실행할 수 있는 with-redefs라고 하는 기능이 있다. ClojureDocs 설명에도 쓰여 있는 것처럼 테스트를 mocking을 할 때 많이 사용한다. 아래 코드는 ClojureDocs 올라와 있는 예제 코드이다. with-redefs 컨택스트
모의 객체(Test double, Mock, Stub)
Test double = 협력관계 객체를 가짜로 세워서 하는 것을 뜻한다. Mock, Stub는 그 가짜 객체이다. Mock > 행위검증을 위해 사용한다(메서드의 리턴 값으로 판단할 수 없는 경우 특정 동작을 수행하는지 검증하는 것) 호출에 대한 기대를 명세한 것이다. Stub > 상태 검증을 위해 사용(메서드가 수행된 후 객체의 상태를 확인하는 것으로 검증)
데브코스 W5D1
Testing Level Unit Testing: 프로그램의 기본 단위인 모듈이 정해진 기능을 수행하는지 테스트 하는 것을 의미한다. Integration Testing: 서로 다른 모듈의 상호작용이 잘 이루어는지 테스트 하는 것을 의미한다. Acceptance Testing: 사용자 시나리오에 맞춰 수행하는 테스트로 애자일 개발 방법론 중 하나인 XP에서 사용하는 용어로 누가 어떤 목적으로 무엇을 하는가에 대한 시나리오가 제대로 수행될 수 있는지 테스트 하는 것을 의미한다. 
XCTest
Test라는 과정은 사실 공학 어디에서든 등장하는 개념이다. 작업에 의존도가 있고, 복잡한 과정으로 넘어갈 수록 이전 단계의 오류는 치명적이기 때문이다. 이를 관리하는 방법이 Test라 할 수 있다. 소프트웨어에서 역시 이러한 개념이 적용된다. 어떤 것인지, 왜 필요한지, 어떻게 할 수 있는지 알아보자. Unit Test 예시 image URLRequest 준비 Task 생성 서버와 통신 Response parsing View Update image 일반적인 이러
2022년 1월 5일 기록
빌더 패턴 lombok을 이용할 경우 @Builder 통해 쉽게 사용할 수 있다. 빌더 패턴 장점 필요한 데이터만 설정할 수 있다. 넣을 필요 없는 필드는 따로 null로 처리 안해도 된다. 가독성이 좋다. 유연성을 확보할 수 이싿. @Builder는 클래스 상단 보다는 생성자 상단에 위치하도록 하라 클래스 상단에 선언하면 비즈니스 로직에서 어떻게 객체를 생성하는지 추척이 어렵다. 개발자의 실수로 필드를 누락하여 null이 들어간 경우 이를 런타임때 발견할 수 있다 . @Transactional 아래와 같은 이점을 준다. transaction begin, commit을 자동 수행해준다. 예외를 발생시키면, rollback 처리를 자동 수행해준다. → C, U, D시 사용 stubbing stubbing은 메소드의 행동을 원하는 대로 미리 정해두는 것을 말한다. verify method 👍
Unit Test란? (단위 테스트)
Unit Test란? Unit test는 프로그래밍을 할 때 소스코드의 특정 모듈(메서드)이 의도된 대로 정확히 작동하는지 검증하는 절차입니다. 다시 말해 작성한 모든 메서드들에 대해서 테스트케이스를 작성하는 것을 의미합니다. Unit Test의 장점 Unit Test를 진행하게 된다면 하나의 기능을 독립적으로 테스트를 하며 코드 변경으로 인해 문제가 발생하여도 짧은 시간안에 해당 문제를 파악할 수 있습니다. 새로운 기능 추가 시 수시로 빠르게 테스트 할 수 있다. 리팩토링 시에 안정성을 확보할 수 있다. 테스팅에 대한 시간과 비용을 절감할 수 있다. 코드에 대한 문서가 될 수 있다. 이러한 장점들이 있어 실무에서는 Unit Test를 선호하고 있다고 합니다. 좋은 Unit Test를 하는 방법 1개의 테스트 함수에 대해서는 assert를 최소화해야한다. 1개의 테스트 함수에는 1가지 개념
May 07, 2021, TIL (Today I Learned) - Mocking the Right Way
학습 내용 Unit Tests: Mocking the right way Fast(빠르게) : 테스트는 빨리 실행되야 한다. 그래서 사람들이 신경쓰지 않는다. Independent/Isolated(독립적/분리된) : 테스트는 따로 설정이나 분리를 해서는 안된다. Repeatable(반복가능한) : 테스트 수행할때마다 동일한 결과를 얻어야 한다. 외부의 데이터 공급자나 동시성(concurrency) 문제로 인해 일시적으로 오류가 발생 할수 있다. Self-validating(자체 검증) : 테스트는 완전히 자동화 되어야 한다. 로그 파일에 대한 프로그래머의 해석보다는 패스(pass)또는 실패(fail)를 출력해야 한다. Timely(적시에) : 이상적인 테스트는 테스트한 생산 코드를 작성하기 전에 작성해야 한다. Given - When - Then Given: 전제조건, 현재 상황 When: 행위 Then: 행위에 의한
[iOS] Test Doubles
Test Doubles Unit Test를 작성하는 동안 production에 사용될 객체와 동일하게 동작하지만 단순화된 버전이 필요한 경우가 있다. 우리는 이런 종류의 객체들을 Test Doubles 이라고 한다. 외부 의존성은 Test Doubles를 통해 관리되며 다양한 시나리오를 쉽게 시뮬레이션할 수 있다 Test Double은 테스트 목적으로 production 객체를 교체하는 모든 객체를 부르는 모든 용어를 말한다. 그리고 이러한 Test Double에는 다섯 가지 종류가 있다 Dummy, Fake, Stub, Spy, Mock 이 Test Doubles들을 알아보기 전에 알아야 하는 개념이 있는데, 상