🚀 트러블 슈팅

🚀 트러블 슈팅

📌 LinkedList의 Unit Test

// LinkedList
struct LinkedList<T: CalculateItem> {
    class Node<T: CalculateItem> {
        fileprivate var value: T
        fileprivate var next: Node?
        
        fileprivate init(_ value: T, next: Node? = nil) {
            self.value = value
            self.next = next
        }
    }
}

// CalculatorItemQueue
struct CalculatorItemQueue<T: CalculateItem> {
    private var list: LinkedList<T> = LinkedList<T>()
}

문제 👻

• LinkedList 타입에 외부에서 직접적으로 접근하는 상황을 방지하고자 은닉화를 위해 CalculatorItemQueue 타입의 list 프로퍼티와 LinkedList 타입에 접근제어를 하려고 하였습니다. 하지만 TDD 테스트 시에도 LinkedList 타입에 접근이 불가능한 문제가 발생하였습니다.

해결 🔫

• CalculatorItemQueue 타입은 LinkedList 타입의 list 프로퍼티를 가지고 있고, CalculatorItemQueue 타입의 메서드는 list 프로퍼티로 실행가능한 메서드(LinkedList 타입 안에 정의된 인스턴스 메서드)를 호출하고 있었습니다.
• 이런 경우, CalculatorItemQueue 타입의 메서드만을 테스트 해도 그 메서드가 호출하는 메서드까지 test coverege가 채워진다는 것을 알게 되었습니다.
• 결국, CalculatorItemQueue 타입만을 테스트 해도 coverege에는 문제가 없기 때문에 LinkedList 타입은 다시 접근제어 하는 것으로 해결하였습니다.

📌 NumberFormatter의 적용

extension String {
    private var numberFormatter: NumberFormatter {
        let numberFormatter = NumberFormatter()
        numberFormatter.numberStyle = .decimal
        numberFormatter.usesSignificantDigits = true
        numberFormatter.maximumSignificantDigits = 20
        
        return numberFormatter
    }
    
    func addComma() -> String {
        guard Double(self) != nil, let result = numberFormatter.string(for: Double(self)) else { return self }
        return result
    }
    
    func addCommaInteger() -> String {
        let components: [String] = self.components(separatedBy: ExpressionText.dot)
        guard let integerPart = numberFormatter.string(for: Double(components[0])) else { return self }
        
        if components.count >= 2 {
            return integerPart + ExpressionText.dot + components[1]
        } else {
            return integerPart
        }
    }
}

문제 👻

• 넘버 포맷터를 사용 자체는 어렵지 않았습니다. 하지만 피연산자를 입력할 때 입력값에 바로 넘버 포맷터를 적용하면 소수점 밑으로 0을 연속으로 입력할 시 생략해버리는 문제가 있었고, 이를 적용하지 않으면 입력값에 콤마(,)가 찍히지 않는 문제가 있었습니다.

해결 🔫

• 이 문제를 해결하기 위해, 바로 넘버 포맷터를 적용하는 메서드와 소숫점 뒷부분은 넘버 포맷터를 적용하지 않고 앞부분만 적용한 후 합치는 메서드를 각각 구현하여 해결하였습니다.

📌 병합 시 테스트 파일 병합에 대한 고민

문제 👻

• 병합 작업을 진행하면서, 테스트 파일을 어떻게 처리해야 하는지 잘 판단이 서지 않았습니다. 각자의 로직에 맞게 테스트 파일을 작성하다보니 병합하는 과정에서 테스트를 다시 수정해야 하는 경우가 많이 발생하였습니다.

해결 🔫

• 테스트 케이스의 구현이 아닌 테스트의 목적에 집중하기로 했습니다. 테스트의 목적이 같다면 그 테스트 내부의 구현이 다를 순 있어도 목적은 같기에 좀 더 가독성이나 로직이 깔끔한 사람의 테스트를 사용하기만 하면 되었습니다.

• 이런 방향성을 가지고 테스트코드의 병합을 진행하였고, 새로운 테스트 케이스가 필요할 시 테스트코드를 추가하는 방식으로 진행하여 문제를 해결하였습니다.

📌 제시된 UML에 포함되지 않았던 View Controller 병합의 어려움

문제 👻

• ViewController의 경우, 프로젝트에서 따로 UML을 제시하시 않았습니다.
• 그 결과, 각자의 방법과 생각으로 구현되어 네이밍 컨벤션, 로직, 메서드나 프로퍼티의 사용에 있어서 각자의 방법이 녹아들어 있는 코드가 완성되었습니다.
• 이 각자의 생각이 녹아져 있는 ViewController를 병합하기 위해 통일된 하나의 기준이 필요했습니다.

해결 🔫

• 저희가 정리한 기준은 다음과 같았습니다.

  • 하나의 메서드가 하나의 작업을 수행하도록 기능분리가 잘 되어있을 것.
  • 예외처리가 가독성 좋게 잘 이루어져 있을 것.
  • 병합 과정에서 예외처리에 오류가 생기지 않도록 할 것.
  • 소스파일을 추가하거나 제거할 경우, 추가 혹은 제거시 사이드 이팩트가 적게 일어나고, 위 사항들이 잘 지켜지는 방향으로 수행할 것.
  • 중복되는 메서드의 경우, 위 사항들이 잘 지켜지는 로직을 채택하거나 두 코드의 로직을 합치는 리팩토링을 진행해 위 사항들을 만족하는 메서드를 채택할 것.

• 다음과 같은 기준을 가지고 병합을 진행하였고, 병합에 있어서 빠르게 취사선택을 할 수 있었습니다.