[개발생각] Test코드 작성시, Fixture의 관리에 대해서

Mock용 객체를 기준값에서 파생되게 만들면, Mock객체의 통일성을 유지할수있고,  서로다른 테스트코드에서도 일관성을 유지하며 테스트코드를 작성할수있다.

 

테스크 코드를 작성할때, Mock용 User정보, Address정보, Device정보등, 테스트 실행시 필요한 정적인, 준비된 데이트들을

Fixture라는 명아래, UserFixture, AddressFixture,DeviceFixture 등의 이름으로 모아두고, 활용하게 된다.

 

여기서 조금만 관리를 소홀히 하면, Fixture클래스는 온갖 데이터가 난무하는고, 중복 코드가 난무하는 클래스, 즉, 애물단지가 되버린다.

여기서 Fixture를 더럽히는 가장 큰 요인하나가, 일관성없는 Mock용 데이터들 정의다.

 

val user1 = User(id=1, name = '가나다41')

val user2 = User(id=9999 name = '안녕333')



val address1 = Address(id='addr1',  userId=1, name = '주소명1')

val address2 = Address(id='address_33333',  userId=20, name = '서울시_xxxxx')



val device1 = Device(id='v-1',  userId=1, name = 'device1')

val device2 = Device(id='v:::0',  userId=22, name = '기계33')

 

이런식으로 개발자 각자가 Fixture에 무심코 정의해서 사용하게되는데, 이런식의 Mock용 데이트들은 결국 중복코드를 만들고,

Fixture안을 더럽히는 주범이 된다.

 

또한, Mock데이트들을 개발,작성자가 임의로 만들게 됨에 따라, 규칙없이 만들게 되어, 같은 userId가 1이라도 name이 가나다41, 안녕333등 전혀 일관성 없는 이름들로 테스트 패키지안에 중복 존재하게 되고, 테스크코드 작성시 이런 중복된 userId를 발견하면,

어떤것을 써야할지 고민 또한 만들게 된다. (같은 user1이 여러개 있는데, 어떤걸 써야할까?!!! 고민)

 

참, 쓸데없는 고민이다... (개발에서 고민거리는 과감하게 없애는 방향으로 코딩을 해야한다고 생각한다. Simple is Best)

 

그래서 이런 Mock데이터들은 해당 비즈니스 서비스에서 가장 기본이 되는 데이터를 중심으로 파생되는 방법으로 작성하게 만들어야 한다.이 방법이 가장 안전하고, 데이터의 일관성을 갖게하여, 관리의 포인트를 줄일수있다.

 

가령, UserId를 기준으로 잡는다면,

위의 Address객체는

 

Value Class UserId(id:Long) 정의했다면,



UserId.toAddress() = Address(id= "addr$id", userId = id,  name = "address$id")

UserId.toDevice() = Device(id= "v$value", userId = id,  name = "device$id")

 

이렇게, UserId기준으로 Address, Device등 파생되는 Mock데이터를 만들게 확장함수를 만들고,

Fixture에 Mock객체를 정의하지말고, Test코드안에서 바로 사용하게 하여, 불필요한 Fixture의 객체 정의를 줄여야 한다.

이런 방법을 사용하면, 한결 간결한 테스트 코드를 작성할수있고,

데이터간의 정합성, 통일성또한 가져갈수있어서, 여러명의 개발자간의 Mock데이터사용이 통일되는 장점이 있다.

 

사용예1)

Test("테스트 코드") {

    val user = getUser(1);

    val mockAddress = user.id.toAddress()

    val mockDevice = user.id.toDevice()

}



사용예2)

Test("테스트 코드") {

    val userId = UserId(1);

    val mockAddress = userId.toAddress()

    val mockDevice = userId.toDevice()

}

 

참, 간결해지고, 명시적이다!!!!

 

테스트 코드를 등한시 하다, 테스트 코드가 복잡해지는 경험을 하게되었고, 고민을 통해, 위와 같은 방법으로 Fixture의 복잡성을 줄이는 방법을 생각해봤다. 테스트 코드도 코딩의 일부이기에, 테스트 코드를 잘 관리하고, 중복코드없게 만드는것 또한 꼭 필요한 작업이다.