오늘도 끄적끄적

Spring Boot Reference의 Testing - Detecting Test Configuration 파트를 보면 다음과 같은 내용이 나온다.

If you are familiar with the Spring Test Framework, you may be used to using @ContextConfiguration(classes=…​) in order to specify which Spring @Configuration to load. Alternatively, you might have often used nested @Configuration classes within your test.
When testing Spring Boot applications, this is often not required. Spring Boot’s @*Test annotations search for your primary configuration automatically whenever you do not explicitly define one.
The search algorithm works up from the package that contains the test until it finds a class annotated with @SpringBootApplication or @SpringBootConfiguration.

Detecting Test Configuration을 위해서 스프링에 친숙하다면 @ContextConfiguration이나 Nested @Configuration이 필요하다고 하고,
Spring Boot를 사용하면 @*Test(@SpringBootTest, @WebMvcTest, @DataJpaTest, etc.)에서 별다른 설정을 하지 않았다면 primary configuration을 찾아나간다고 한다.

N줄 요약

글이 길어지다보니 아무도 안 볼 거 같고, 집중을 하고 소스코드를 따라가면서 읽어야해서 우선 먼저 요약을 적어놓는다.

1
2
3

dependencies {
    compileOnly("org.springframework.boot:spring-boot-starter-web:2.4.0")
}

runtime classpath에는 추가되지 않아서 원래는 java.lang.ClassNotFoundException이 나야 정상이다.
하지만 IntelliJ의 Spring Boot Configuration으로 실행하면 실행이 잘만 된다.

실제로 classpath를 찍어보면 아래와 같이 spring-boot-starter-web을 포함하고 있다.

JUnt 4

Field Injection 밖에 되지 않음.
Spring Boot 2.2.0부터 JUnit 5가 기본으로 탑재되기 시작했고,
Spring Boot 2.4.0부터는 아예 JUnit 4 의존성이 제거됐기 때문에 JUnit 4의 사용은 하지 말아야한다.

1
2
3
4
5
6
7
8

@RunWith(SpringRunner::class)
@SpringBootTest
class SomeTest {
    @Autowired
    private lateinit var a: SomeComponent
    @Test
    fun contextLoad() {}
}

JUnit 5

JUnit 5의 @ExtendedWith 어노테이션을 이용하면 테스트 전/후로 다양한 일을 할 수 있다.
@ExtendedWith 어노테이션은 어노테이션에 명시한 Extension들을 실행하는 역할 뿐이 하지 않는다.

SpringProperties 클래스

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

// ...
import java.util.Properties;
// ...
public final class SpringProperties {

    private static final String PROPERTIES_RESOURCE_LOCATION = "spring.properties";
    
    private static final Properties localProperties = new Properties();


    static {
        try {
            ClassLoader cl = SpringProperties.class.getClassLoader();
            URL url = (cl != null ? cl.getResource(PROPERTIES_RESOURCE_LOCATION) :
                    ClassLoader.getSystemResource(PROPERTIES_RESOURCE_LOCATION));
            if (url != null) {
                try (InputStream is = url.openStream()) {
                    localProperties.load(is);
                }
            }
        }
        catch (IOException ex) {
            System.err.println("Could not load 'spring.properties' file from local classpath: " + ex);
        }
    }
    // ...
    @Nullable
    public static String getProperty(String key) {
        String value = localProperties.getProperty(key);
        if (value == null) {
            try {
                value = System.getProperty(key);
            }
            catch (Throwable ex) {
                System.err.println("Could not retrieve system property '" + key + "': " + ex);
            }
        }
        return value;
    }
    // ...
}

1. PROPERTIES_RESOURCE_LOCATION(spring.properties) 파일을 읽어서 InputStream에 넣고
2. localProperties.load(is)를 통해 Properties에 위에서 읽어들인 InputStream을 load 하고
3. 나중에 필요할 때 키 값을 통해 프로퍼티를 불러오고 있다.

localProperties는 Properties라는 자바 표준 API를 사용하고 있기 때문에 저 spring.properties에는 어떻게 키와 프로퍼티를 구성하는지 알아보자.

Properties

TDD By Example 책을 보다가 감명 받은 부분을 정리해봤다.
기본적으로 아래 4가지 원칙을 따라 진행한다.

1. Red - 실패하는 작은 테스트를 작성(최초에는 컴파일 조차 되지 않음)
2. Green - 빨리 테스트가 통과하게 끔 수정(이를 위해선 어떠한 죄악도 용서됨)
3. Refactoring - 모든 중복을 제거(2번에서 수행한 죄악들을 청산)

해당 포스트는 프랑(CHF, 스위스 통화)을 달러($)로 변환하는 간단한 테스트를 작성하는 것부터 시작한다.

프랑에서 달러로 변환하기

아래와 같은 간단한 코드들을 이번 예제에서 사용해보자.

TDD By Example 책을 보다가 감명 받은 부분을 정리해봤다.
기본적으로 아래 4가지 원칙을 따라 진행한다.

1. Red - 실패하는 작은 테스트를 작성(최초에는 컴파일 조차 되지 않음)
2. Green - 빨리 테스트가 통과하게 끔 수정(이를 위해선 어떠한 죄악도 용서됨)
3. Refactoring - 모든 중복을 제거(2번에서 수행한 죄악들을 청산)

책에서는 달러($)와 프랑(CHF, 스위스 통화)의 연산에 대한 조그만 테스트를 시작으로 두 통화 사이의 중복을 제거해나갔다.
해당 포스트는 클라이언트에 영향 없이 상속 구조를 마음껏 고칠 수 있는 방법에서 제거하지 못한 중복인 plus 메서드를 제거하는 것으로 시작한다.
(기본적으로 코틀린, JUnit5, kotest를 사용했다)
기본적인 내용은 내가 감명깊게 느낀 부분을 설명하기 위해 TDD로 진행해나가는 과정이고 실제 이 포스트의 핵심은 마치며를 보면 된다.

각 하위 클래스에 있는 plus 메서드 제거하기

기본적으로 소스 코드는 아래와 같다.

TDD By Example 책을 보다가 감명 받은 부분을 정리해봤다.
기본적으로 아래 4가지 원칙을 따라 진행한다.

1. Red - 실패하는 작은 테스트를 작성(최초에는 컴파일 조차 되지 않음)
2. Green - 빨리 테스트가 통과하게 끔 수정(이를 위해선 어떠한 죄악도 용서됨)
3. Refactoring - 모든 중복을 제거(2번에서 수행한 죄악들을 청산)

책에서는 달러($)와 프랑(CHF, 스위스 통화)의 연산에 대한 조그만 테스트를 시작으로 두 통화 사이의 중복을 제거해나갔다.
해당 포스트도 위 두가지 통화에 대해 덧셈 연산을 테스트 하는 작은 코드로 시작한다.
(기본적으로 코틀린, JUnit5, kotest를 사용했다)
기본적인 내용은 내가 감명깊게 느낀 부분을 설명하기 위해 TDD로 진행해나가는 과정이고 실제 이 포스트의 핵심은 하위 클래스의 직접적인 참조 줄이기를 보면 된다.

Dollar 클래스 구현하기

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class DollarTest {
    @Test
    fun `$5 + $2 = $7`() {
        // Given
        val five = Dollar(5)
        val two = Dollar(2)

        // When
        val actual = five + two

        // Then
        val expected = Dollar(7)
        actual shouldBe expected
    }
}

themes/next/_config.yml을 보면 아래와 같이 기본적으로 ‘더 읽어보기’가 세팅돼있다.

1
2
3
4
5
6
7
8
9

# Automatically excerpt (Not recommend).
# Use <!-- more --> in the post to control excerpt accurately.
auto_excerpt:
  enable: true
  length: 150

# Read more button
# If true, the read more button would be displayed in excerpt section.
read_more_btn: true

하지만 NexT Theme 7.6.0 이상의 버전에서는 위와 같이 설정이 돼있어도 ‘더 읽어보기’가 나오지 않는다.
이럴 때는 hexo-excerpt 플러그인을 설치해주면 해결된다. 🎉
https://github.com/theme-next/hexo-theme-next/issues/1245#issuecomment-558486354

If you are using NexT 7.6.0 and later, please install the plugin: https://github.com/chekun/hexo-excerpt

인증서는 왜 쓸까

A가 데이터를 보냈는데 이게 진짜 A가 보낸 건지 아닌지를 검증할 수가 없다.
인증서는 A라는 사람이라는 것을 보증해주는 문서라고 보면 된다.
따라서 A한테 메세지가 올 때 A의 인증서가 오지 않는다면 A라고 취급을 하지 않으면 된다.
하지만 개나소나 인증서를 발급할 수 있으면 A 행세를 아무나 낼테니까 **인증된 기관(CA, Certificate Authority)**으로부터 적절한 절차를 거쳐 인증서를 발급받을 수 있다.

우리가 알고 있는 TLS 인증서(https 도메인마다 발라져있는) 같은 경우에도 이런 절차를 거쳐 발급된다.
그리고 이런 인증서들은 **X.509(공개키 인증서 포맷의 표준)**라는 표준을 준수한다.

막연하게 양방향 암호화 하면 당연스레 AES를 떠올리고, 제대로 모른 채로 사용했다.
이제부터라도 조금은 알고 써야겠다는 생각이 들어서 살짝 정리해봤다.

양방향/단방향 암호화

양방향 암호화는 암호화 및 복호화가 가능하다는 소리다.
휴대폰 번호 등등 민감한 개인정보는 암호화 해서 저장해야하는데 고객 정보를 식별하기 위해선 복호화도 가능해야한다.
혹시나 키와 DB가 털린다면 복호화가 가능하므로 적어도 개인정보는 마스킹 한 후에 암호화해서 저장해야한다.
양방향 암호화 알고리즘에는 DES(보안에 취약), AES, SEED(국내에서 개발, 공인인증서에 사용됨) 등등이 있다.

단방향 암호화는 암호화만 가능하고 복호화는 불가능하다는 소리다.
비밀번호와 같이 암호화 한 값들끼리 단순히 비교만 하면 되고, 복호화 할 필요가 없는 정보들은 단방향 암호화 해야한다.
혹시나 키와 DB가 털려도 복호화가 불가능하기 때문에 암호화된 값만 알 수 있지 원본 비밀번호는 알 수 없기 때문에 양방향 암호화 보다는 좀 더 안전하다.
이런 특성 때문에 비밀번호 찾기 대신에 비밀번호 재설정 기능 밖에 지원 할 수 없다. (비밀번호 찾기를 지원해주는 사이트는 보안이 매우 안 좋은 사이트이다.)
단방향 암호화 알고리즘에는 해시 알고리즘이 사용되며 SHA256, SHA512, MD5(무작위 대입 공격에 약함) 등등이 있다.