Backend Language

Spring Security 및 Jwt를 이용하여 로그인 로직을 구현하던 중, 다음과 같은 에러가 발생하였다. org.springframework.security.authentication.BadCredentialsException: 자격 증명에 실패하였습니다. at org.springframework.security.authentication.dao.DaoAuthenticationProvider.additionalAuthenticationChecks(DaoAuthenticationProvider.java:80) at org.springframework.security.authentication.dao.AbstractUserDetailsAuthenticationProvider.authenticate(Ab..

🥀 테스트 범위와 종류 예를 들어, 개발 완료 후에 진행하는 테스트를 통합 테스트라고 부르는데, 고객 입장에서 요구한 기능을 올바르게 구현했는지 수행하는 테스트를 인수 테스트라고 부른다. 이처럼, 테스트와 관련 용어는 문맥이나 사용자에 따라 의미가 다를 수 있다. 🌻 기능 테스트(Functional Test) 와 E2E 테스트 사용자 입장에서 시스템이 제공하는 기능이 올바르게 동작하는지 확인한다. 이 테스트를 위해서는 시스템을 구동하고 사용하는데 필요한 모든 구성요소가 필요하다. 사용자가 직접 사용하는 웹 브라우저나 모바일 앱부터 시작하여 데이터베이스나 외부 서비스에 이르기까지 모든 구성 요소를 하나로 엮어 진행 브라우저(끝) ~ 데이터베이스(끝)까지 모든 구성요소를 완전히 논리적으로 하나의 기능으로 다..

🥨 테스트가 어려운 코드 개발을 진행하다보면, 테스트하기 어려운 코드들을 만나게 된다. 테스트하기 어려운 코드들은 다음과 같다. 1. 하드 코딩된 경로 2. 의존 객체를 직접 생성 3. 정적 메소드 사용 4. 실행 시점에 따라 달라지는 결과 5. 역할이 섞여 있는 코드 6. 그 외 테스트가 어려운 코드 🍗 하드 코딩된 경로 하드 코딩된 경로라함은 다음과 같이 코딩되어 있는 것을 뜻한다. Path path = Paths.get("D:\\data\\pay\\cp0001.csv"); 다음과 같이 되어 있는 코드를 테스트 하려면 해당 경로에 파일이 반드시 위치해 있어야 한다. 하지만, 윈도우에 다음과 같은 드라이브가 없거나 윈도우 전용 파일 경로이기 때문에 맥 OS, 리눅스에서는 파일을 열 수 없어 다른 OS를..

🔒 대역의 필요성 [외부 요인이 테스트에 관여하는 주요 예] 테스트 대상에서 파일 시스템 사용 테스트 대상에서 DB로부터 데이터를 조회하거나 데이터를 추가 테스트 대상에서 외부의 HTTP 서버와 통신 테스트 대상이 위와 같은 외부 요인에 의존하여 사용하는 외부 API 서버가 일시적으로 장애가 발생하면 테스트를 원활하게 수행할 수 없다. 또한, 내부 DB를 사용하더라도 데이터 구성을 항상 같게 진행하기는 어렵다. 다음과 같은 외부 요인은 테스트 작성을 어렵게 만들 뿐만 아니라 테스트 결과도 예측할 수 없게 만든다. 테스트 대상에서 의존하는 요인 때문에 테스트가 어려울 때에는 대역을 써서 테스트를 진행한다. 외부 요인으로 인해 테스트가 어려울 때, 외부 요인을 대신하는 대역이 외부 요인을 대신하여 테스트에 ..

🌺 Mockito란 모의 객체 생성, 검증, 스팁을 지원하는 프레임워크이다. 이는, 인기있는 자바 모의 객체 프레임워크 중 하나로, 이를 통해 대역을 보다 원활하게 사용할 수 있게 된다. 🌺 dependencies 추가 (Gradle) dependencies { implementation 'org.springframework.boot:spring-boot-starter' testImplementation 'org.springframework.boot:spring-boot-starter-test' // junit testImplementation('org.junit.jupiter:junit-jupiter:5.5.0') // mockito -> 이부분 추가 testImplementation('org.mock..

🍀 기능에서의 상황 File file = new File("data.txt"); long sum = MathUtils.sum(dataFile); 다음과 같은 코드는 파일이 없거나 잘못 작성된 상황에서 에러가 발생하게 된다. 이 때, 잘못됨을 인지하고 Exception 처리를 하거나 문제 상황을 return 을 해주어야 한다. 이처럼 예외 상황을 찾아내고 코드에 반영하여 비정상을 막아내야 한다. 가능한 예외상황을 다 찾아내기 위해 노력해야하고 그렇게 함으로써 개발한 소프트웨어의 품질을 높일 수 있다. 🍀 테스트 코드의 구성 요소: 상황, 실행, 결과 확인 테스트 코드: 기능을 실행하고 그 결과를 확인 따라서, 상황(given), 실행(when), 결과(then)으로 구성할 수 있다. [상황이 주어지고, 상..

🍰 JUnit 5 모듈 구성 JUint 플랫폼 테스팅 프레임 워크를 구동하기 위한 런처와 테스트 엔진을 위한 API wprhd JUnit Jupiter JUnit 5를 위한 테스트 API와 실행 엔진 구성 JUnit Vintage JUnit 3, 4로 작성된 테스트를 5 플랫폼에서 실행하기 위한 모듈 제공 Jupiter로 테스트를 작성하고 실행하려면 build.gradle 파일 내 dependencies에 의존을 추가해주어야 한다. 다음은 TDD 스터디 프로젝트의 build.gradle file이다. Jupiter 관련 의존성이 추가된 것을 확인할 수 있다. plugins { id 'java' id 'org.springframework.boot' version '2.7.7' id 'io.spring.de..

⭐ 기능 명세 파워포인트: 스토리 보드 형태 이메일: 간단한 형태 지라: 같은 이슈를 통해 추가할 기능의 명세 회의 자리: 구두로 전달 사용자에게 기능을 전달하기 위해서는 기능을 입력과 결과의 형태여야 한다. 입력: 보통 메서드의 파라미터 결과: 여러 형식으로 정의 리턴 값 등,, 변경 (회원 가입에서는 DB의 값을 추가하면서 시스템의 상태를 변경하는 것으로 리턴하는 것과 다름) 1. 스토리 보드를 포함한 다양한 형태의 요구사항 문서를 이용해서 기능 명세 구체화 2. 기능 명세를 구체화하는 동안 입력과 결과를 도출 3. 도출한 기능 명세를 코드에 반영 (기능의 이름, 파라미터, 리턴 타입 등이 결정) ⭐ 설계 과정을 지원하는 TDD [과정] 1. 테스트 코드 생성 2. 코드를 구현하고 리팩토링 하는 과정..

💛 테스트 코드 작성 순서 1. 쉬운 경우에서 어려운 경우로 진행 2. 예외적인 경우에서 정상적으로 진행 그렇다면 어려운 경우로 작성하면 안되는 이유는 뭘까? 🌱 초반에 복잡한 테스트부터 시작하면 안되는 이유 초반에 복잡하게 시작하면 한 번에 구현해야 하는 코드가 많아진다. if 문이 늘어날 수도 있고 한번에 많은 코드를 만들다보면 나도 모르게 버그를 만들고 나중에 버그를 잡기 위해 많은 시간을 허비하게 된다. 🌱 구현하기 쉬운 테스트부터 시작하기 보통 수분 내에 구현을 완료하고 통과할 수 있는 테스트 구현을 선택해야 한다. Chapter 2에서 했던 암호 강도 측정 예에서는 다음 중 하나가 쉬울 것이다. 1. 모든 조건에서 충족하는 경우 2. 모든 조건에서 충족하지 않는 경우 1번의 경우 모든 조건을 ..

소속된 GDSC MJU에서 TDD 스터디를 시작하여, 다음 책을 정리하는 블로그 포스팅을 진행하고자 한다. 테스트 주도 개발 시작하기 - YES24 TDD(Test-Driven Development)는 테스트부터 시작한다. 구현을 먼저 하고 나중에 테스트하는 것이 아니라 먼저 테스트를 하고 그다음에 구현한다. 구현 코드가 없는데 어떻게 테스트할 수 있을까? 여기 www.yes24.com 🍀 TDD Chapter 1: TDD 개발 준비 간단하기 때문에 build.gradle 설정만 작성하고 넘어간다. dependencies { implementation 'org.springframework.boot:spring-boot-starter' testImplementation 'org.springframework..