database by narae :p

JPA 연관 관계가 있는 엔티티 생성 패턴

dbbymoon — Thu, 9 Mar 2023 04:48:24 +0900

Objective

JPA 연관 관계가 있는 엔티티를 생성하기 위해서는 연관 엔티티를 var nullable 타입으로 선언하여 생성해야 합니다. 하지만 데이터로 보았을 때 해당 엔티티는 var 타입도 nullable 타입도 아니길 원하는 경우 val non-nullable 타입으로 설정하고 JPA 엔티티를 생성하는 패턴에 대해 공유합니다.

Background

OrderEntity.kt

OrderProductEntity.kt

OrderService.kt

@Service
class OrderService(
	private val orderRepository : OrderRepository
) {
	fun saveOrder(param : OrderCreateParam) {
		val order = OrderEntity(
				orderId = param.orderId
		)
		val orderProductList = param.orderProductList.map {
				OrderProductEntity(
						order = order
				)
		}
		order.orderProductList = orderProductList

		orderRepository.save(order)
	}
}

OrderEntity 를 먼저 생성하고, 먼저 생성한 Order와 함께 OrderProductEntity를 생성하여 orderProductList를 set 해야 한다.
번거로운 것은 둘째치고, orderProductList의 타입이 var이라서 언제 어디서 바뀔 수 있다는 단점이 있다.

⇒ 그래서 저는 orderProductList를 val로 사용하고 싶었습니다..

알고 있는 데이터들만 가지고 생성자를 호출하고, init 에서 처리하자

CreateOrderParam.kt

data class CreateOrderParam(
    val userId: Long,
    val orderProductList: List<CreateOrderProductParam>
)

data class CreateOrderProductParam(
    val productId:  Long
)

생성자 파라미터로 넘길 클래스입니다. 이 클래스만 가지고 Service 코드에서 OrderEntity를 생성할 것입니다.

OrderService.kt

@Service
class OrderService(
	private val orderRepository : OrderRepository
) {
	fun saveOrder(param : CreateOrderParam) {
		val order = OrderEntity(param)
		orderRepository.save(order)
	}
}

서비스 코드는 이렇게 될 것입니다.

OrderEntity.kt

@Entity
@Table(name = "ORDER")
class OrderEntity(createOrderParam: CreateOrderParam) {
    @Id
    @Column(name = "ORDER_ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val orderId: Long? = null

    @OneToMany(
        cascade = [CascadeType.ALL],
        fetch = FetchType.LAZY,
        mappedBy = "order",
        targetEntity = OrderProductEntity::class
    )
    val orderProductList: List<OrderProductEntity>

    @Column(name = "USER_ID")
    val userId: Long

    init {
        this.userId = createOrderParam.userId
        this.orderProductList = createOrderParam.orderProductList.map {
            OrderProductEntity(
                createOrderProductParam = it,
                order = this
            )
        }
    }
}

OrderEntity 의 init 에서 프로퍼티를 초기화하고, OrderProductEntity를 생성할 때 order로는 this 키워드를 통해 OrderEntity를 넘깁니다.

OrderProductEntity.kt

@Entity
@Table(name = "ORDER_PRODUCT")
class OrderProductEntity(
    createOrderProductParam: CreateOrderProductParam,
    order: OrderEntity,
) {
    @Id
    @Column(name = "ORDER_PRODUCT_ID")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val orderProductId: Long? = null

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "ORDER_ID", referencedColumnName = "ORDER_ID")
    val order: OrderEntity

    @Column(name = "PRODUCT_ID")
    val productId: Long

    init {
        this.order = order
        this.productId = createOrderProductParam.productId
    }
}

OrderProductEntity 에서는 생성자에서 받은 OrderEntity로 order를 초기화해줍니다.

코틀린의 init

생성자를 통해 인스턴스가 만들어질 때 호출되는 함수입니다.
인스턴스가 만들어질 때, init 내부의 코드를 통해 프로퍼티를 초기화할 수 있습니다.
여기서 발생할 수 있는 문제가 있는데요…

init 내부에서 초기화하는 프로퍼티를 final 로 설정하라는 문구가 뜹니다.
- 참고 링크
- 이 경우 Derived 에서는 NPE 가 발생할 수 있습니다.
- Base의 init 코드를 수행 시 size 프로퍼티를 사용하는데, Derived의 size는 items.size 로 초기화하고 있습니다. 하지만 이 때, items는 초기화가 되지 않은 시점이니 NPE가 발생합니다.⇒ 따라서, open class의 init 내부에서 접근하는 어떤 프로퍼티는 하위 클래스에 의해 조작되어 예외가 발생할 수 있는 상황들이 있어 final 프로퍼티로 사용하는 것이 좋습니다.

open class Base {
    open val size: Int = 0
    init { 
				println("size = $size") 
		}
}

class Derived : Base() {
    val items = mutableListOf(1, 2, 3)
    override val size: Int get() = items.size
}

기본 생성자에 컬럼에 대응하는 프로퍼티들이 없어도 될까?

Hibernate는 클래스의 인스턴스를 생성할 때 reflection 기법을 사용하여 객체를 초기화 한다.
필드와 컬럼을 매핑하는 @Column 어노테이션을 통해 매핑할 수 있기 때문에 기본 생성자에 꼭 컬럼에 대응하는 필드들이 있어야 하는 것이 아닙니다.

결론

연관 관계가 있는 엔티티를 생성할 때 연관 엔티티를 꼭 var nullable type으로 설정하지 않아도 생성할 수 있는 패턴을 적용해보았다.
호불호가 갈릴 수 있기 때문에 팀원들의 의견이 궁금합니다.
혹시 발생할 수 있는 문제는 없을지도 이야기 해주시면 감사하겠습니다.

JPA @OneToMany - targetEntity

dbbymoon — Thu, 9 Mar 2023 03:43:51 +0900

Objective

JPA의 @OneToMany 연관 관계에서 연관 엔티티가 open class 인 경우 read-only 컬렉션을 사용하지 못하고 Mutable 컬렉션을 사용하도록 하는데, 원인과 read-only 컬렉션을 사용할 수 있는 해결 방안을 공유합니다.

Background

build.gradle.kts

allOpen {
	annotation("javax.persistence.Entity")
	annotation("javax.persistence.MappedSuperclass")
	annotation("javax.persistence.Embeddable")
}

OrderEntity.kt

OrderProductEntity.kt

Error Message

One To Many 속성 값의 데이터는 ‘? extends OrderProductEntity’ 가 될 수 없다.

Collection has neither generic type or OneToMany.targetEntity() defined: 
moonee.order.storage.db.core.entity.OrderEntity.orderProductList

컬렉션은 제네릭 타입을 가질 수 없거나, OneToMany의 targetEntity를 정의해야 한다.

원인

public interface List<out E> : Collection<E>

List는 공변성을 가진다.
- 공변적이다 ?
  - 하위 타입 관계가 유지된다.
  - A가 B의 하위 타입일 때, List<A>가 List<B>의 하위타입이다.
  - A가 B의 하위 타입일 때, List<A> 타입의 값이 들어갈 자리에 List<B> 타입의 값을 사용할 수 있다.
- 코틀린의 클래스는 기본적으로 final이나, allOpen 설정을 통해 @Entity 클래스는 상속 가능한 클래스이다.
  - orderProductList의 타입을 List<OrderProductEntity> 로 하게 되면, List<OrderProductEntity> 타입이 들어올 수도, OrderProductEntity 를 상속한 List<? extends OrderProductEntity 타입이 들어올 수도 있다.
Hibernate는 Collection 타입에 대해 Generic 타입을 허용하지 않는다.
- 런타임에서 타입이 동적으로 바뀔 수 있는 것을 지원하지 않는다.
- 뭔가 관련된 것 같은 문서를 발견했는데 정확한 해석이 어렵습니다. (참고)

Solution

Solution 1. MutableList를 사용한다 ?

Intellij 에서는 이 경우, MutableList를 사용하라고 권고한다.
왜 MutableList는 될까?
- 왜냐하면…. MutableList는 무공변이다. out 키워드가 없음.

⇒ 하지만 orderProductList는 변경되지 않는 데이터이기 때문에 MutableList로 사용하고 싶지 않다. (탈락)

Solution 2. Entity를 상속 불가능하게 한다 ?

OrderProductEntity가 open class 이기 때문에, List 를 사용하면 정확히 어떤 타입이 들어올지 알 수 없으니 발생하는 오류라고 판단해서 allOpen 설정을 지워봤다.
…. 그러니까 해결은 됐다.
하지만, 몇 주 전 케브님의 JPA 지연로딩 뽀개기 에서 들었듯이, @~ToOne 관계에서 지연로딩을 할 때 JPA는 해당 클래스를 상속하여 프록시를 만드는 방식으로 지연 로딩을 한다고 했다.

⇒ 그래서 allOpen을 지우는 건 좋은 해결책은 아니다.

Solution 3. val 을 사용한다.

@OneToMany(cascade = [CascadeType.ALL], fetch = FetchType.LAZY, mappedBy = "order")
val orderProductList: List<OrderProductEntity>

var 대신 val 를 사용하면 생성할 때 초기화되고 바뀌지 않기 때문에 List 를 사용할 수 있는 것 같았다.

⇒ 하지만 OrderProductEntity 는 order 또는 orderId 를 가지고 있기 때문에, OrderEntity를 생성하면서 동시에 OrderProductEntity를 생성할 수 없기 때문에 val 를 사용하기 어렵다.

Solution 4. targetEntity 속성을 이용한다.

번역 / (선택 사항) 연결 대상인 엔터티 클래스입니다. 컬렉션 속성이 Java 제네릭을 사용하여 정의된 경우에만 선택 사항입니다. 달리 지정해야 합니다. 제네릭을 사용하여 정의된 경우 컬렉션의 매개 변수화된 유형이 기본값입니다.

그렇다고 합니다. 사용하니까 해결되었습니다.
아마 JPA 에게 OrderProductEntity 또는 ? extends OrderProductEntity 타입들 중 어떤 타입을 사용할지 정확하게 알려주는 것이니 해결이 되었다고 이해했습니다.

결론

targetEntity 속성을 이용하자
Hibernate의 implicit Polymorphism 에 대해 조금 공부해보고 싶은데 어렵다. (같이 보실 분 모집합니다)
- https://docs.jboss.org/hibernate/core/3.3/reference/en/html/inheritance.html#inheritance-tableperconcreate-polymorphism

테스트 주도 개발 주기의 유지

dbbymoon — Sun, 5 Dec 2021 17:54:16 +0900

테스트 주도 개발로 배우는 객체 지향 설계와 실천

5장. 테스트 주도 개발 주기의 유지

5.1. 각 기능을 인수 테스트로 시작하라

실패하는 인수 테스트를 작성하는 것으로 신기능을 작업하는데 착수한다. 인수테스트는 우리가 작성하려는 기능을 아직 시스템에서 갖추지 못했다는 사실을 보여주고 그 기능이 완성되기까지 진행 상황을 반영한다.

인수 테스트 : 응용 도메인에서 나온 용어만 이용한다. (기반 기술. db 등 용어가 아닌)

=> 자동으로 확인 가능한 형태로 요구 사항을 정확하게 표현하면 분명하게 드러나지 않는 가정을 밝히는데 도움이 된다.

=> 실패하는 테스트 덕에 요구사항을 충족하는 데 필요한 만큼의 기능만 구현하는 데 집중할 수 있어 기능을 완성할 가능성이 높아진다.

=> 사용자 관점에서 시스템을 바라보게 되어 구현자 관점에서 기능을 짐작하지 않고 사용자가 필요로 하는 것을 이해하게 된다.

단위 테스트 : 객체나 작은 객체 집합을 격리된 상태에서 시험한다.

인수 테스트는 단위 테스트를 거친 객체를 대상으로 통합 테스트를 수행하고, 프로젝트를 진행시킨다.

5.2. 회귀를 포착하는 테스트와 진행 상황을 측정하는 테스트를 분리하라

인수테스트 통과 주기 : 중첩 피드백 고리를 구동하는 엔진에 해당

단위테스트, 통합테스트 : 개발 팀을 보조하고 빠르게 실행되어야 한다. 항상 통과해야 한다.
완성된 기능에 대한 인수 테스트 : 실행하는데 시간이 오래 걸려도 회귀를 포착하고 늘 통과해야 한다.

5.3. 테스트를 가장 간단한 성공 케이스로 시작하라

동작 가능한 가장 간단한 것을 테스트

간단한 != 지나치게 단순화한

=> “피드백을 받을 수 있는” 가장 간단한 것을 테스트해라

가장 간단한 성공 케이스로 테스트를 시작

5.4. 읽고 싶어 할 테스트를 작성하라

테스트를 시스템이나 객체에서 수행할 행위로 가능한 “명확”하게 표현

테스트가 잘 읽히면 그 다음으로 지원하는 기반 구조를 만든다.

테스트가 어떻게 해야 할지 기술하는 명확한 오류 메시지를 보이면서 예상대로 실패하면 보조적인 역할을 하는 코드를 충분히 구현했다는 사실을 알게 된다. 그러면 해당 테스트를 통과시키는 코드를 작성하기 시작하면 된다.

5.5. 테스트가 실패하는 것을 지켜보라

TDD 주기의 일부로 진단 절차 개선하기

=> 실패 시, 진단 정보를 확인

=> 오류 메시지가 코드와 관련된 문제로 이끌 때까지 테스트 코드를 조정하고 테스트를 재실행

=> 보조 코드를 확장하거나 수정해서 오류 메시지를 늘 명확하고 의미 있게 만든다.

오류 메시지를 검사해야 하는 이유

=> 유용한 진단 정보를 생성하는 고생을 감내하면 테스트, 코드에서 해야할 일이 무엇인지 분명하게 하는데 도움이 된다.

5.6. 입력에서 출력 순서로 개발하라

외부 이벤트를 받는 객체에서 중간 계층을 거쳐 중심 도메인 모델로 나아간 다음, 외부에서 확인 가능한 응답을 생성하는, 다른 경계에 위치한 객체에까지 => 시스템을 처음부터 끝까지 만들어 나간다.

*** 새 도메인 모델 객체에 단위 테스트를 수행한 후 애플리케이션의 나머지 부분에 해당 객체를 끼워 넣는 식으로 시작하는 것이 쉬워 보일 지라도 나중에 통합 문제로 어려움을 겪을 수 있다. => 불필요하거나 올바르지 않은 기능을 구현했을 수 있음. 도메인 모델을 먼저 작업할 때는 올바른 피드백을 받을 수 없기 떄문

5.7. 메서드가 아닌 행위를 단위 테스트하라

보통 메서드 테스트를 먼저 생각함

=> 메서드 테스트는 “목적”이 무엇인지 알려주지 않는다.

제공해야 하는 기능에 집중

*** 메서드 테스트로는 각 객체의 동작 방식, 즉 객체의 책임이 무엇이고, 객체의 여러 메서드가 함께 어떻게 동작하는지 이해하기 어렵다.

5.8. 테스트에 귀를 기울여라

테스트하기 어려운 코드 영역

=> 설계 개선이 필요 !

지금 당장 코드를 테스트하기 어렵게 만드는 구조 때문에 나중에도 코드를 변경하기 어려워질 것.

테스트를 작성하는 과정 => 잠재적인 유지 보수 문제를 조기에 알려주는 경고 표시

*** 예상치 못한 변화를 예상하라 : 설계에 취약함이 보일 때 리팩토링을 통해 시스템 품질을 유지한다면 어떠한 변화가 일어나도 거기에 대응할 수 있을 것.

5.9. 주기의 미세 조정

너무 큰 단위로 테스트 수행 => 코드의 모든 가능한 경로를 시도하는 “조합 폭발” 현상 발생
너무 작은 단위로 테스트 수행 => (예를 들면, 클래스 수준으로만) 테스트는 쉽지만 함께 동작하지 않는 객체에 대한 문제는 놓치게 될 것

TDD를 진행하며 취약한 부분을 찾아보고, 테스트 전략을 조정한다.
로직에서 성가신 부분은 단위 테스트(아니면 단순화)가 더 필요할 수 있다.
처리하지 않은 예외에는 통합 수준의 테스트가 더 필요할 수 있다.
예상치 못한 시스템 실패에는 조사가 더 필요하거나, 테스트를 더 철저하게 해야할 수 있다.

테스트 주도 주기 시작

dbbymoon — Sun, 5 Dec 2021 17:53:54 +0900

테스트 주도 개발로 배우는 객체 지향 설계와 실천

4장. 테스트 주도 주기 시작

테스트는 인수테스트의 일환으로 전 구간을 대상으로 실행되어 시스템의 외부 인터페이스에 관해 필요한 피드백을 줘야하는데, 이는 자동화된 빌드/배포/테스트 주기 전체를 구현해야 함을 의미한다.

4.1. 우선 동작하는 골격을 대상으로 테스트하라

‘동작하는 골격’을 대상으로 빌드, 배포, 테스트하는 방법을 파악한 다음, 그 기반 구조를 이용해 유의미한 첫 기능에 대한 인수 테스트를 작성한다. 그 후에는 시스템의 나머지 부분을 대상으로 테스트 주도 개발을 진행할 수 있게 모든 것이 제자리에 놓일 것이다.

동작하는 골격 : 전 구간을 대상으로 자동 빌드, 배포, 테스트를 할 수 있는 실제 기능을 가장 얇게 구현한 조각을 말한다.
테스트 과정에서의 배포 단계가 필요한 이유

4.2. 동작하는 골격의 외형 결정

동작하는 골격 : 애플리케이션의 개괄적인 구조를 결정하기 시작

이를 설계하기 위해서는 ‘시스템의 목적’을 이해해야 한다.

클라이언트의 요구 사항, 즉 기능적 요구사항과 비기능적 요구 사항을 고수준 관점에서 바라보고 의사 결정에 참고해야 한다.

팀에서 자신들의 해법(코드 작성 시작하기 전 반드시 취해야 할 필수적인 의사 결정)을 전체적으로 조망하는데 이바지하게끔 첫 테스트를 작성하는 과정을 활용해 프로젝트의 맥락을 짚어낸다.

문제 이해
대략적인 설계(아키텍처)
자동화 : 빌드, 배포, 전 구간 테스트
TDD
배포 가능 시스템

4.3. 피드백 소스 구축

빌드 및 테스트 자동화를 활용해 시스템 품질에 관한 피드백을 받을 수 있다.

특정 버전을 떼어내서 배포하기가 얼마나 쉬운가
설계가 얼마나 잘 동작하는가
코드 품질은 얼마나 높은가

등…

=> 도메인에 관해 얼마나 잘 이해하고 있는지, 현장에서 시스템을 볼 수 있다는 것이 고객의 우선 순위를 바꾸는 것이 아닌지에 대한 피드백을 받을 수 있다.

=> 이로서 철저한 회귀 테스트 모음을 갖게된다

=> 중대한 변경을 안전하게 할 수 있다.

4.4. 불확실성은 일찍 드러내라

테스트를 나중에 했을 때 프로젝트에서 나타나는 불확실성

도구 소개

dbbymoon — Sun, 5 Dec 2021 17:51:24 +0900

테스트 주도 개발로 배우는 객체 지향 설계와 실천

3장. 도구 소개

3.2. JUnit4

리플렉션을 통해 클래스 구조를 파악한 후 해당 클래스 내에서 테스트를 나타내는 것을 모두 실행

테스트 케이스 : @Test

Junit4에서는 테스트를 실행할 때 테스트 클래스의 새 인스턴스를 생성한 후 적절한 테스트 메서드를 호출한다. 매번 새 테스트 객체를 생성하기 때문에 각 테스트 간의 격리성을 확보할 수 있다.

단정

테스트 대상 객체를 호출하고 그 결과를 단정(aseertion)

- assertTrue()

- aseertNull()

- aseertEquals()

예외 예상

@Test(expected=….Exception.class)

테스트 픽스처

: 테스트가 시작할 때 존재하는 고정된 상태

- 테스트가 반복 가능함을 보장. 테스트가 실행될 때마다 해당 테스트는 동일한 상태로 시작하므로 동일한 결과를 낸다.

- 테스트가 실행되기 전에 준비해서(set up) 테스트 실행이 완료된 후에 정리(tear down)한다.

- 픽스처는 해당 테스트를 정의한 클래스에서 관리하고 객체의 필드에 저장된다. 같은 클래스에 정의된 테스트는 모두 동일한 픽스처를 가지고 시작하며, 실행될 때 해당 픽스처를 변경해도 된다.

- 픽스처는 필드 초기화자(initi9ializer)에서 준비한다. 또 테스트 클래스의 생성자나 인스턴스 초기화자 블록에서 픽스처를 준비할 수도 있다. @Before, @After

테스트 러너

: 클래스를 대상으로 리플렉션을 수행해 테스트를 찾아 해당 테스트를 실행한다.

3.3. 햄크레스트 매처와 assertThat()

햄크레스트 : 매칭 조건을 선언적으로 작성하는 프레임워크
매처 : 특정 객체가 어떤 조건과 일치하는지 알려주며, 해당 조건이나 객체가 어떤 조건과 일치하지 않는 이유를 기술한다.
assertThat(a, b).= assertTrue(a.matches(b))

3.4. jMock2: 목 객체

목 객체를 동적으로 생성하여 목을 생성하려는 타입의 구현체를 직접 작성하지 않아도 된다.
테스트 대상 객체가 그것과 상호 작용 중인 목 객체를 어떻게 호출하고 목 객체가 거기에 반응해 어떻게 동작해야 할지를 지정하는 API를 제공한다.

모조 객체 : 테스트 대상 객체의 콘텍스트. 그것과 이웃하는 객체를 표현
목 객체 : 테스트가 실행되는 과정에서 테스트 대상 객체의 실제 이웃을 대신
예상 구문 : 테스트 과정에서 테스트 대상 객체가 그것의 이웃을 어떻게 호출해야 하는지 기술

cafe24 거래대사

그룹관리자 / 관리자

상점관리자 merchantId

그룹관리자 companyType

onboarding - ……..

객체를 활용한 테스트 주도 개발

dbbymoon — Sun, 5 Dec 2021 17:51:06 +0900

테스트 주도 개발로 배우는 객체 지향 설계와 실천

2장. 객체를 활용한 테스트 주도 개발

2.1. 객체망

객체지향설계 : 객체 간의 의사소통에 집중.
협업하는 객체의 망

2.2 값과 객체

값 : 변하지 않는 양이나 크기
객체 : 시간이 지남에 따라 상태가 변할지도 모르지만 식별자가 있는 계산 절차

2.3. 메시지를 따르라

다른 객체와 쉽게 관계를 맺을 수 있게 객체를 설계하면, 고수준의 선언적 접근법이 주는 혜택을 누릴 수 있다. 객체가 일반적인 의사소통 패턴을 따르고 객체 간의 의존성이 명시적임을 의미한다.

의사소통 패턴 : 객체들이 다른 객체와 상호작용하는 방법을 관장하는 각종 규칙으로 구성
객체

역할 : 관련된 책임의 집합
책임 : 어떤 과업을 수행하거나 정보를 알아야할 의무
협력 : 객체나 역할의 상호작용

2.4. 묻지 말고 답하라

호출하는 객체가 무엇을 원하는지 기술하고, 호출된 객체가 그러한 바를 어떻게 실현할 지 결정하게 해야한다. (디미터의 법칙)

객체는 그것이 내부적으로 보유하고 있거나 메시지를 통해 확보한 정보만 가지고 의사결정을 내려야 한다.

호출자는 객체의 내부 구조나 역할 인터페이스 너머에 존재하는 시스템의 나머지 구조에 관해 전혀 알 필요가 없다.

2.5. 그래도 가끔은 물어라

호출자에 질의메서드를 추가해 가장 적절한 객체에 행위가 자리 잡아 행위에 이해하기 쉬운 이름이 생기고 테스트하기가 쉬워진다.

2.6. 협력 객체의 단위 테스트

테스트에 존재하는 대상 객체의 이웃을 다른 대체물(목 객체, mock object)로 대체

=> 발생하는 이벤트에 대해 대상 객체가 가짜 이웃과 어떻게 상호 작용할지 지정할 수 있다.

= 예상 구문(expectation)

테스트가 진행되는 동안 목 객체는 자신이 예상대로 호출되었는지 단정한다.
나머지 테스트가 동작하는데 필요한 행위(스텁 형태로 동작하는)를 구현하기도 한다.

2.7. 목 객체를 활용한 TDD 지원

과정
테스트 핵심 구조

단위 테스트는 대상 객체와 해당 객체를 둘러싼 환경 간의 관계를 명확하게 드러낸다.

그곳에 있는 모든 객체를 생성하고 대상 객체와 해당 객체의 협력자 사이의 상호 작용에 관한 단정을 만들어 낸다.

테스트 주도 개발의 핵심은 무엇인가?

dbbymoon — Sun, 5 Dec 2021 17:50:48 +0900

테스트 주도 개발로 배우는 객체 지향 설계와 실천

1장. 테스트 주도 개발의 핵심은 무엇인가?

1.1 학습 과정으로서의 소프트웨어 개발

소프트웨어 프로젝트 : 사람 + 응용 분야 + 기술 등

미처 예상하지 못한 요소가 많음

개발자들은 구성 요소의 동작 방식을 배우면서 프로젝트를 마무리한다.

: 불확실한 변화를 예측하려면 경험이 늘어남에 따라 불확실성을 해결하는데 도움이 될 프로세스가 필요하다.

1.2. 피드백은 가장 기본적인 도구다

경험에 의거한 피드백을 이용해 시스템과 그 용도에 관해 배운 후, 그 배운바를 시스템에 적용

배포 : 내린 가정을 검사할 기회 => 실제 진행 상황을 측정하고, 오류를 탐지하고 수정하고, 배운 바에 따라 현재 계획을 조정한다.

점진적이고 반복적인 개발

: 중첩된 피드백 고리의 집합으로 구성된 프로젝트에는 개발이 점진적이고 반복적이다.

점진적인 개발 : 모든 계층과 구성요소를 구축한 다음 시스템을 기능별로 구축한다. 각 기능은 시스템의 모든 관련 부분에 걸쳐 전 구간에 이르는 조각으로 구현한다. 시스템은 언제나 통합된 상태이며 배포할 준비가 되어있다.
반복적인 개발 : 계속해서 충분한 상태에 이를 때까지 피드백에 응답해 기능 구현을 다듬는다.

1.3. 변화를 돕는 실천법

회귀 오류를 잡아줄 꾸준한 테스트 : 기존 기능을 망가뜨리지 않고도 새 기능을 추가할 수 있다.
테스트 자동화 : 구축과 배포, 시스템 버전 변경에 드는 비용을 줄이려면 테스트를 자동화해야 한다.
코드 단순화 : 코드 설계를 개선하고 단순화하고, 중복을 제거하고, 코드가 명확하게 자신의 역할을 표현하게끔 코드를 사용할 때마다 꾸준히 코드를 리팩토링해야한다.

TDD => 테스트를 설계활동으로. 테스트를 사용해 코드에서 하고 싶은 바에 관한 생각을 명확하게 한다.

개발 내내 테스트를 작성한다면 변경에 대한 자신감을 주는 자동화된 회귀테스트를 구축할 수 있다.

1.4. 테스트 주도 개발 간단 정리

TDD

과정
작성할 때의 장점
실행할 때 장점

=> 실패하는 테스트 없이는 새 기능을 작성하지 말라.

국부적으로 생각하고 국부적으로 행동하라

리팩토링 : 기존 코드의 작동 방식을 바꾸지 않은 채로 기존 코드의 내부 구조를 변경하는 것. 구현하는 기능의 표현을 개선해 코드를 좀 더 유지보수할 수 있게 만드는 것.
리팩터링은 이해하기 쉽고 안전할 정도로 규모가 작아야 한다.

1.5. 좀 더 큰 그림

클래스를 대상으로 한 단위 테스트만 작성할 때 문제점

아무데서도 호출하지 않거나, 시스템의 나머지 부분과 통합할 수 없는 테스트가 발생

인수 테스트 : 만들고자 하는 기능을 시험하는 테스트

기능을 대상으로 작업할 때 작성하려는 코드가 실제로 필요한지 가늠한다.
즉, 직접 관련된 코드만 작성한다.

=> 언제 코드 작성을 멈춰야 하는지 = 코드 작성을 어디서 시작해야 하는지

실패하는 인수 테스트 작성

진척도를 측정하는 수단
테스트 스위트가 증가하면 시스템을 변경할 때 회귀 실패에서 보호받을 수 있다.

실패하는 단위테스트 작성 -> 테스트 통과 -> 리팩터링

코드 품질 유지

1.6. 전 구간 테스트

인수테스트에서는 시스템 내부 코드를 가능한 한 직접 호출하지 말고 시스템 전 구간을 시험해야 한다.

: 외부에서 유입되는 시스템하고만 상호 작용한다.

1.7. 테스트의 수준

인수 테스트 : 전체 시스템이 동작하는가?
통합 테스트 : 변경할 수 없는 코드를 대상으로 코드가 동작하는가?
단위 테스트 : 객체가 제대로 동작하는가? 객체를 이용하기가 편리한가?

1.8. 외부 품질과 내부 품질

외부 품질 : 시스템이 고객과 사용자의 요구를 얼마나 잘 충족하는가(기능, 신뢰성, 가용성, 응답성 등)
내부 품질 : 시스템이 개발자와 관리자의 요구를 얼마나 잘 충족하는가(이해하기 쉬운가, 변경하기 쉬운가 등) => 시스템의 동작 방식을 안전하고 예상 가능한 상태로 바꿀 수 있게 만드는 것이 중요

전구간 테스트
단위 테스트

결합도 : 한 변경이 다른 것의 변경을 강제한다면 요소들이 결합된 상태
응집도 : 해당 요소의 책임이 의미 있는 단위를 형성하는지 나타내는 척도

도커 + ELK 분산 환경 셋팅

dbbymoon — Sun, 24 May 2020 14:51:52 +0900

# 단일 서버

git clone https://github.com/deviantony/docker-elk.git
cd docker-elk

vi elasticsearch/config/elasticsearch.yml

xpack.security.enabled: false

docker stack deploy -c docker-stack.yml elk

docker ps
docker service ls

## 레플리카 모드

vi docker-stack.yml

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.6.2
    ports:
      - "9200"
      - "9300"
    configs:
      - source: elastic_config
        target: /usr/share/elasticsearch/config/elasticsearch.yml
    environment:
      cluster.name: "docker-cluster"
      node.name: elk_elasticsearch.{{.Task.Slot}}
      discovery.seed_hosts: tasks.elasticsearch
      cluster.initial_master_nodes: elk_elasticsearch.1,elk_elasticsearch.2,elk_elasticsearch.3
      node.master: "true"
      node.data: "true"
      ES_JAVA_OPTS: "-Xmx256m -Xms256m"
      ELASTIC_PASSWORD: changeme
    networks:
      - elk
    deploy:
      mode: replicated
      replicas: 3

vi elasticsearch/config/elasticsearch.yml

network.host: [ _eth0_, _eth1_, _lo_ ]
network.publish_host: _eth0_

sudo sysctl -w vm.max_map_count=262144

## 글로벌 모드

vi docker-stack.yml

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.6.2
    hostname: elasticsearch-{{.Node.Hostname}}
    ports:
      - "9200:9200"
      - "9300:9300"
    configs:
      - source: elastic_config
        target: /usr/share/elasticsearch/config/elasticsearch.yml
    environment:
      cluster.name: "docker-cluster"
      node.name: elasticsearch-{{.Node.Hostname}}
      discovery.seed_hosts: elasticsearch
      cluster.initial_master_nodes: elasticsearch-laptop
      node.master: "true"
      node.data: "true"
      ES_JAVA_OPTS: "-Xmx256m -Xms256m"
      ELASTIC_PASSWORD: changeme
    networks:
      - elk
    deploy:
      mode: global

도커 Docker 정리 1

dbbymoon — Sat, 16 May 2020 16:01:45 +0900

- 컨테이너형 가상화 기술을 구현하기위한 상주 애플리케이션
- 이 애플리케이션을 조작하기 위한 명령행 도구(CLI)
로 구성되는 프로덕트.

애플리케이션 배포에 특화되어 있기 때문에 애플리케이션 개발 및 운영을 컨테이너 중심으로 할 수 있다.
- 컨테이너 : 도커가 만들어내는 게스트 운영체제

# 특징

## 개발환경 구축

로컬 환경에 도커만 설치하면 몇줄짜리 구성파일(Dockerfile)과 명령어 한 줄로 애플리케이션이나 미들웨어가 이미 갖춰진 테스트용 가상환경(도커 컨테이너)을 빠르게 구축할 수 있다.
가상화 소프트웨어와 비교해도 오버헤드가 적어진다는 장점이 있다.

## 운영 환경

도커는 개발 후 운영 환경에 대한 배포나 애플리케이션 플랫폼으로 가능하다.
기존 가상화 소프트웨어보다 더 가볍게 동작하기 때문에, 테스트 환경 뿐만 아니라 운영 환경에서도 컨테이너를 사용할 수 있다.

## 이식성

로컬 머신의 도커 환경에서 실행하던 컨테이너를 다른 서버에 있는 도커 환경에 배포하거나, 반대로 다른 서버의 도커 환경에서 동작하던 컨테이너를 로컬로 가져올 수 있다.
즉, 개발 환경과 운영 환경을 거의 동등하게 재현할 수 있다.

## 컨테이너 간의 연동
## 클라우드 플랫폼 지원

# 도커의 기본 개념

## 컨테이너 가상화 기술

가상화 소프트웨어 없이도 운영체제의 리소스를 격리해 가상운영체제로 만들 수 있다.
이 가상운영체제를 '컨테이너'라고 한다.
컨테이너를 만들면서 발생하는 오버헤드는 다른 가상화 소프트웨어보다 더 적다. 빠르게 시작 및 종료할 수 있고 이에 들어가는 리소스도 적은 편이다.
컨테이너를 쉽게 만들고, 사용하고 버릴 수 있다.
<-> 호스트 운영체제형 가상화 : 운영체제 위에서 가상화 소프트웨어를 사용해 하드웨어를 에뮬레이션 하는 방법으로 게스트 운영체제를 만드는 방식. 컨테이너 가상화와 비교했을 때 구조적으로 오버헤드가 더 크다.

### LXC (LinuX Containers)

단일 컨트롤 호스트 상에서 여러 개의 고립된 리눅스 시스템(컨테이너)들을 실행하기 위한 운영 시스템 레벨 가상화 방법
=> 시스템 컨테이너. 단순한 리소스 분리 목적으로 애플리케이션 배포 용도는 아님
=> LXC에서 복제한 애플리케이션을 다른 LXC 호스트에서 실행했을 때 LXC 설정 차이로 인해 기대했던 대로 애플리케이션이 동작하지 않는 등의 문제가 있음

### 도커 vs LXC

- 호스트 운영 체제의 영향을 받지 않는 실행 환경 (Docker Engine을 이용한 실행 환경 표준화)
- DSL(Dockerfile)을 이용한 컨테이너 구성 및 애플리케이션 배포 정의
- 이미지 버전 관리
- 레이어 구조를 갖는 이미지 포맷(차분 빌드가 가능)
- 도커 레지스트리 (이미지 저장 서버 역할을 함)
- 프로그램 가능한 다양한 기능의 API

## Dockerfile

컨테이너 정보를 Dockerfile 코드로 관리
이 코드를 기반으로 복제 및 배포가 이루어지기 때문에 재현성이 높다.
도커 이전에는 애플리케이션을 호스트 운영체제 또는 게스트 운영체제에 배포하여, 애플리케이션이 운영체제의 영향을 강하게 받는다.
도커는 컨테이너에 애플리케이션 실행환경이 함께 배포되는 방식. 아예 실행환경 자체를 배포하는 방식.
=> 따라서 도커는 환경의 영향을 덜 받고 배포가 간편.

# 도커 스타일 체험하기

1. helloworld 쉘 스크립트 파일 생성

#!/bin/shecho 

"Hello World"

2. Dockerfile 생성

FROM ubuntu:16.04

COPY helloworld /usr/local/bin
RUN chmod +x /usr/local/bin/helloworld

CMD ["helloworld"]

- FROM 절 : 컨테이너의 원형(틀) 역할을 할 도커 이미지(운영체제)를 정의
FROM openjdk:8-jre
- RUN 절 : 도커 컨테이너 안에서 어떤 명령을 수행하기 위한 것
RUN adduser -disabled-password -gecos '' grip
- COPY 절 : 파일을 도커 컨테이너 안의 경로에 복사
- CMD 절 : 완성된 이미지를 도커 컨테이너로 실행하기 전에 먼저 실행할 명령을 정의

3. 도커에 이미지 빌드

docker image build -t helloworld:latest .

4. 도커 컨테이너 실행

docker container run helloworld:latest

더블 디스패치 double dispatch

dbbymoon — Tue, 7 Jan 2020 19:08:10 +0900

의존 관계

Supplier의 변화가 Client에 영향을 주는 경우
- Supplier가 Client의 필드
- Supplier가 Client 메소드의 파라미터
- Supplier가 Client의 로컬 변수
- Supplier로 메시지를 보냄

=> 재사용 가능한 객체 지향 설계/개발이 어렵다.
Client는 재사용이 어렵다
Client는 컴포넌트/서비스가 될 수 없다.

오브젝트 패턴은 런타임시 바뀔 수 있는, (상속 관계보다) 더 동적인 오브젝트 (의존) 관계를 다룬다.
- 생성 관련 패턴 (Creational Pattern) : 객체 인스턴스 생성을 위한 패턴으로, 클라이언트와 그 클라이언트에서 생성해야 할 객체 인스턴스 사이의 연결을 끊어주는 패턴
싱글턴, 팩토리 메소드, 추상 팩토리, 프로토타입, 빌더 패턴
- 행동 관련 패턴 (Behavioral Pattern) : 클래스와 객체들이 상호작용하는 방법 및 역할을 분담하는 방법과 관련된 패턴
스트래티지, 옵저버, 스테이트, 커맨드, 이터레이터, 템플릿 메소드, 인터프리터, 미디에이터, 역할 변경, 메멘토, 비지터
- 구조 관련 패턴 (Structural Pattern) : 클래스 및 객체들을 구성을 통해서 더 큰 구조로 만들 수 있게 해 주는 것과 관련된 패턴
데코레이터, 어댑터, 컴포지트, 퍼사드, 프록시, 브리지, 플라이웨이트

Method dispatch

어떤 메소드를 실행할지 결정하는 것

# static dispatch

class Service {
    void run() {
        System.out.println("run()");
    }
}

public static void main(String[] args) {
    new Service().run();
}

컴파일 되는 시점에 컴파일러가 어떤 클래스의 메소드를 수행하는지 알고 있고 바이트 코드도 남는다.

# dynamic dispatch

abstract class Service {
    abstract void run();
}

class ServiceImpl extends Service {
    void run() {
        System.out.println("run()");
    }
}

public static void main(String[] args) {
    Service service = new ServiceImpl();
    service.run();
}

어떤 메소드를 실행하는지 컴파일 시점에 모름. 추상클래스의 메소드를 호출하는 것만 알고 있음.
런타임 시점에 service에 할당된 객체가 무엇인지 확인하고 메소드를 실행함

Double Dispatch

Dynamic Dispatch를 두 번 하는 것

* 예시. SNS, Post

1. 구현체에 따라 로직이 다르지 않은 경우

interface Post {
    void postOn(SNS sns);
}
class Text implements Post {
    public void postOn(SNS sns) {
        // text -> sns
    }
}
class Picture implements Post {
    public void postOn(SNS sns) {
        // picture -> sns
    }
}

interface SNS {};
class Facebook implements SNS {

}
class Twitter implements SNS {

}

    public static void main(String[] args) {
        List<Post> posts = Arrays.asList(new Text(), new Picture());
        List<SNS> sns = Arrays.asList(new Facebook(), new Twitter());

        posts.forEach(p -> sns.forEach(s -> p.postOn(s)));
    }

SNS의 구현체에 따라 로직이 달라지는 경우를 고려하지 않음

2. SNS의 구현체에 따라 로직이 다른 경우 (분기문 사용)

interface Post {
    void postOn(SNS sns);
}
class Text implements Post {
    public void postOn(SNS sns) {
        if(sns instanceof Facebook) {
            // text -> facebook
        } else if(sns instanceof Twitter) {
            // text -> twitter
        } else {
            throw new IllegalArgumentException();
        }
    }
}
class Picture implements Post {
    public void postOn(SNS sns) {
         if(sns instanceof Facebook) {
            // picture -> facebook
        } else if(sns instanceof Twitter) {
            // picture -> twitter
        } else {
            throw new IllegalArgumentException();
        }
    }
}

interface SNS {};
class Facebook implements SNS {

}
class Twitter implements SNS {

}

- SNS의 새로운 구현체가 생기면 분기문을 추가해야 함
- 만약 실수로 분기문을 추가하지 않으면 의도치 않게 exception 발생

3. SNS의 구현체에 따라 로직이 다른 경우 (메소드 오버로딩 사용. static dispatch)

interface Post {
    void postOn(SNS sns);
}
class Text implements Post {
    public void postOn(Facebook facebook) {
        // text -> facebook
    }

    public void postOn(Twitter twitter) {
        // text -> twitter
    }
}
class Picture implements Post {
    public void postOn(Facebook facebook) {
        // picture -> facebook
    }

    public void postOn(Twitter twitter) {
        // picture -> twitter
    }
}

interface SNS {};
class Facebook implements SNS {

}
class Twitter implements SNS {

}

이전 코드와 달리 메소드 오버로딩을 사용해 분기문을 제거함

하지만 다음 코드 중 s -> p.postOn(s) 에서 컴파일 시점에 에러 발생

    public static void main(String[] args) {
        List<Post> posts = Arrays.asList(new Text(), new Picture());
        List<SNS> sns = Arrays.asList(new Facebook(), new Twitter());

        posts.forEach(p -> sns.forEach(s -> p.postOn(s)));
    }

- 메소드 오버로딩은 static dispatch 이므로 컴파일 시점에 어떤 클래스의 메소드를 수행할지 알아야 함
- 하지만 s는 SNS라는 interface의 타입이기 때문에 어떤 구현체(Facebook, Twitter 등)의 타입인지 컴파일러가 알 수 없음

오류 발생. 실패 !!!!!!!

Double Dispatch 사용

interface Post {
    void postOn(SNS sns);
}

class Text implements Post {
    public void postOn(SNS sns) {
        sns.post(this);
    }
}

class Picture implements Post {
    public void postOn(SNS sns) {
        sns.post(this);
    }
}

interface SNS {
    void post(Text text);
    void post(Picture picture);
}

class Facebook implements SNS {
    public void post(Text text) {
        // text -> facebook
    }
    public void post(Picture picture) {
        // picture -> facebook
    }
}

class Twitter implements SNS {
    public void post(Text text) {
        // text -> twitter
    }
    public void post(Picture picture) {
        // picture -> twitter
    }
}

    public static void main(String[] args) {
        List<Post> posts = Arrays.asList(new Text(), new Picture());
        List<SNS> sns = Arrays.asList(new Facebook(), new Twitter());

        posts.forEach(p -> sns.forEach(s -> p.postOn(s)));
    }

- 한 단계를 더 거친 것 같지만, 분기문을 사용하지 않고 dynamic dispatch를 두 번 사용
- Post 중 어떤 구현체의 postOn 메소드를 실행할지 dynamic dispatch 한 번 사용
- postOn 메소드 내부에서 SNS 중 어떤 구현체의 post 메소드를 실행할지 dynamic dispatch 한 번 사용

=> 새로운 구현체가 생기는 경우에는 다음과 같이 구현체에 대한 코드만 작성하면 됨

class Instagram implements SNS {
    public void post(Text text) {
        // text -> instagram
    }
    public void post(Picture picture) {
        // picture -> instagram
    }
}

- 구현체를 새로 추가하는 것이 자유로움 => 기존에 의존하던 코드에 직접적으로 영향을 주지 않는다.

=> 비지터 패턴으로 예를 들면, SNS가 visitor 역할을 하고 Post의 메소드 postOn()이 accept() 역할

Visitor Pattern

위의 코드로 예를 들면,

- Post는 SNS 타입의 어떤 구현체가 들어오는지 관심 없고, postOn() 메소드 (accept) 를 제공
- SNS의 구현체(visistor)의 post() 메소드 (visit) 를 통해 실제 로직을 실행할 수 있음
- SNS의 구현체가 새로 추가되어도 Post에는 영향을 미치지 않음
- Post의 구현체가 추가된다면 ? 어쩔 수 없이 SNS에 Post의 구현체를 처리하는 메소드를 다 추가해 줘야 함. SNS의 구현체에 따라 로직이 다르지 않고 모두 공통 로직을 사용한다면 SNS를 abstract class로 작성해서 사용해도 됨.

Visitor Proxy Pattern (hibernate)

* polimophic query

List<SNS> sns = repository.findSNS();

이 list의 요소들을 instanceof로 타입을 체크하면 실패한다.
- JPA에서 각각의 요소들은 프록시 구조로 반환되기 때문에 타입은 SNS 타입이기 때문.
- 따라서, 이 때는 반드시 visitor 패턴을 사용해야 함.

=> 따라서, 프록시를 visitor로 해서 타입을 체크할 수 있다. 이를 일반화해서 proxy visitor pattern 이라고 함