📅 TIL - 2025-12-01
✨ Keyword 요약
- 시저 암호 구현 -
String.toCharArray()와 아스키코드 값 활용- 테스트 코드
💻 코딩테스트
🔹 문제(프로그래머스)
- 문제: 시저 암호
🔹 풀이 접근 방식
- 사용한 알고리즘: -
시저 암호를 구현한 거라 내용 자체가 알고리즘이라고 보면 되지 않을까? - 시간복잡도: O(n)
*n = 문자열 길이 - 예외 처리나 경계 조건:
배열을 사용하지 않고 문자열을 순회함과 동시에 반환값을 만들고 싶었다.
그런데 초기 구현 코드에서는 아스키코드 값을 기준으로 하다 보니 n값의 범위에 따라 대문자와 소문자 근처에 있는 특수문자가 출력되는 경우가 생기더라.if문/else-if문으로 문자가 ' ' / 대문자 / 소문자인 경우로 나눠 반환값을 만드는 방식으로 수정했다.
🔹 코드 스니펫
// 처음 구현했던 코드
class Solution {
public String solution(String s, int n) {
StringBuilder sb = new StringBuilder();
for(int i=0; i < s.length(); i++) {
if(s.charAt(i) == ' ') {
sb.append(" ");
continue;
}
char asc = s.charAt(i);
if((asc + n) > 122 || ((asc + n) > 90 && (asc + n) < 97)) {asc = (char) (asc + n - 26);}
else { asc = (char) (asc + n); }
sb.append(asc);
}
return sb.toString();
}
}⬇️
// 수정한 코드
class Solution {
public String solution(String s, int n) {
StringBuilder sb = new StringBuilder();
for(char c : s.toCharArray()) {
if(c == ' ') {
sb.append(' ');
}
else if(c <= 'Z' && c >= 'A') {
sb.append((char) ((c + n - 'A') % 26 + 'A'));
}
else if(c <= 'z' && c >= 'a') {
sb.append((char) ((c + n - 'a') % 26 + 'a'));
}
}
return sb.toString();
}
}🧑🏫 TIL
🔹 테스트 코드
왜 테스트 코드를 작성해야 할까?
- 회귀 테스트 대상 기능이 클 수록(=범위가 넓을 수록) 안정성이 떨어진다.
- 테스트 케이스로 문서화를 편리하게 작성할 수 있다.
API 명세, 또는 테스트 문서화 등에 그대로 활용 가능 - 기능의 성공/오류에 관해 작성한 테스트 코드는 다른 사람에게 정보를 전달할 수 있는 수단으로도 사용할 수 있다.
➡️ 개발 기간이나 작업 크기(기능)이 커질 수록 회귀 테스트에 쓰이는 비용(시간, 기능범위)가 커지기 때문
테스트 피라미드
1. Unit Test
: 단위 테스트는 프레임워크에 의존하지 않고 코드를 테스트, Mocking을 활용함
Spring 프로젝트 내에서 완료할 수 있는 범위
2. Integration Test
: 실제 DB/Spring Context등을 포함해 여러 Component의 동작을 테스트
3. UI Test
: 실제 사용자의 사용 과정을 테스트 → 인력과 시간 비용이 발생
📝 회고 및 메모
🔹 질의응답 내역
-
본 프로젝트에서 전역 예외 처리(사용자 정의된
BusinessException.class)를 구현했을 경우 테스트 코드에서 예외 처리 케이스를 구현할 때도BusinessException.class로 응답 예시를 작성해야 하나요?
아니면 세부적인 예외(IllegalArgumentException.class등)로 작성해야 하나요?
➡️ (통합테스트 관점에서)본래 프로젝트에서 사용자 정의한 예외 처리가 잘 이뤄지는지 확인해야 하기 때문에 전역 예외처리 버전(BusinessException.class)으로 해야 한다.
단위테스트에서는 세부 예외 처리 확인? -
외부 mocking 서버를 사용하는 테스트 방식이 실제 DB와 요청/응답 흐름을 모방하는 방식이니까 프로젝트 내부에서만 진행되는 테스트보다 신뢰도가 더 높다고 볼 수 있나요?
➡️ 관점에 따라 다르다. 프로토콜에 대한 신뢰도를 기준으로 평가한다면 신뢰도가 높다고 볼 수 있겠지만, 단순히 Value 전달을 테스트하는 관점에서 봤을 때 두 방식은 신뢰도의 차이가 없다. 그러나 비용의 차이는 있다. -
@MockBean으로 등록된 객체랑@Mock으로 생성된 객체의 차이는? 그리고 두 어노테이션은 서로 영향을 주는지?
➡️@MockBean은@Bean을 대체하는 것,@Mock은 객체를 대체하는 것. 서로 영향을 주진 않는다. -
@MockBean으로 하는 방법과@Autowired로 잡는 방법은 뭐가 다른가요?
➡️ 진짜 객체를 사용하느냐@Autowired, 대체된 Bean 객체를 가져오느냐@MockBean의 차이.
