첫 실무 test code 작성 및 고민

2023-03-02 작성된 글입니다.

 

 

import {describe, expect, it} from '@jest/globals'
import convertToIndexGroup from './converToIndexGroup'

describe('convert array to index group object', () => {
  describe('group by 4 item', () => {
    const ITEM_NUMBER_IN_EACH_ARRAY = 4
    it('given length one array', () => {
      expect(convertToIndexGroup([{id: 0}], ITEM_NUMBER_IN_EACH_ARRAY)).toEqual(
        {
          0: [{id: 0}],
        },
      )
    })
    it('given length 5 array', () => {
      expect(
        convertToIndexGroup(
          [{id: 0}, {id: 1}, {id: 2}, {id: 3}, {id: 4}],
          ITEM_NUMBER_IN_EACH_ARRAY,
        ),
      ).toEqual({
        0: [{id: 0}, {id: 1}, {id: 2}, {id: 3}],
        1: [{id: 1}, {id: 2}, {id: 3}, {id: 4}],
      })
    })

    it('given length 9 array', () => {
      expect(
        convertToIndexGroup(
          [
            {id: 0},
            {id: 1},
            {id: 2},
            {id: 3},
            {id: 4},
            {id: 5},
            {id: 6},
            {id: 7},
            {id: 8},
          ],
          ITEM_NUMBER_IN_EACH_ARRAY,
        ),
      ).toEqual({
        0: [{id: 0}, {id: 1}, {id: 2}, {id: 3}],
        1: [{id: 4}, {id: 5}, {id: 6}, {id: 7}],
        2: [{id: 5}, {id: 6}, {id: 7}, {id: 8}],
      })
    })
  })
})

기쁜 나머지... 아무 맥락도 없는 전체 코드 투척.

 

지난번에 작성한 2023.02.27 - [BTY/TypeScript] - index signature 관련 타입 에러 글 속 기능의 테스트 코드를 작성했다!

해당 함수는 간단히 말해...

object들이 담긴 array와, 한 번에 보여야 할 item들의 개수를 전달받아,

각 index number를 key로, value로 전달받은 number만큼의 item이 담긴 배열을 지닌 객체를 반환한다!

(맞다! 유사 페이지네이션이다!)

이 때 특이한 점은, 맨 마지막 index number의 value는 항상  전달받은 number만큼 꽉 차있어야 한다는 것.

 

작고 소중한 첫 번째 테스트를 통과한 후... 들었던 생각들.

 

1. 테스트의 범위는 어디까지일까?

해당 기능에서 주의해야할 사항은 다음과 같았다.

• 각 배열에 담겨야하는 item 수(ITEM_NUMBER_IN_EACH_ARRAY)만큼 잘 담기는지?
• 여러 길이의 배열도 의도한 값이 반환되는지?

이를 표현하기 위해 'group by 4 item'란 맥락으로 describe 한 후, array의 length만큼 test를 작성했다.

그렇다면... array length를 몇 개나 테스트하면 좋은 걸까?

지금은 담겨야 할 item 수가 4개니 → 분기점이 될만한 length 1, 5, 9에 대한 테스트를 작성했다.

이걸로 테스트가 완료된 걸까? 더 많은 케이스를 작성해둬야 하는 건 아닌가?

그렇다면... 충분한 양의 테스트는 얼마나 되는 거지?

 

심지어 이는 item수가 4개일 때만인데. 담길 item수가 2개, 8개, 10개인 상황은? 모든 상황에서 의도한 값이 반환되는 걸 테스트하고 싶다면... 이를 몽땅 작성해야 하는 걸까? 

 

2. 테스트 코드를 잘못 작성하면 끝장이다 → 효율적인 테스트 코드 작성 습관이 필요하다

마지막 테스트('given length 9 array')가 몇 번씩 실패했다.

뭐지..? 하며 에러 로그를 봤더니, 테스트 코드에서 마지막 item의 id를 잘 못 작성한 것 아닌가!

(즉 테스트 코드의 matchers함수 내에서 의도와 다른 반환값을 적어둔 것...)

전형적인 밈인 '테스트 코드를 테스트하는 코드를 테스트하는 테스트 코드'가 필요했던 상황인데...

 

이러한 문제가 발생한 원인은

→ 테스트 코드 작성 시, 해당 예시 데이터를 일일이 하드코딩 했기 때문!

array 요소들을 복사 붙여 넣기 하다 보니 중복된 id값이 들어가고만 것이었다.

 

따라서 다음번에는 테스트 코드를 작성할 때도 충분한, 어쩌면 실제 코드보다 더한 주의를 기울여야 할 테며

더불어 테스트 코드 작성 시에도 읽기 쉽고, 유지보수가 간편한 코드가 되도록 노력해야만 한다!