델리게이트 패턴
에 대해서 이전보다 이해가 됐다. 정확히는 위임자와 대리자의 관계를 이해했다.테스트 코드
를 먼저 짜고 코드 구현에 들어갔다. TDD에서 RGR(red-green-refactor)와 BDD(given-when-then)을 적용해서 해봤다. 내가 원하는 결과를 테스트 할 수 있는 테스트 코드를 먼저 짜고 테스트 코드가 green이 될 때 까지 일단 필요한 구조체와 메소드를 만들었다. 그리고 XCTAssertEqual이나 XCTAssertNotEqual을 쓰기 위해서 비교가 필요한 클래스에 extension으로 Equatable
프로토콜을 채택해서 구현했다.code coverage
: 테스트 코드가 동작하는 범위와 동작하지 않은 범위(우측에 붉은 색으로 나타난다)를 알 수 있다.CustomStringConvertible
프로토콜로 해결. (어차피 카드 정보를 반환하는 메소드를 구현해야 했음.)struct Point: CustomStringConvertible {
let x: Int, y: Int
var description: String {
return "(\(x), \(y))"
}
}
let p = Point(x: 21, y: 30)
let s = String(describing: p)
print(s)
// Prints "(21, 30)"
출처 : 애플 공식 홈페이지
CaseIterable
프로토콜에 구현된 allCases 메소드를 사용할 수 있다.enum CompassDirection: CaseIterable {
case north, south, east, west
}
print("There are \(CompassDirection.allCases.count) directions.")
// Prints "There are 4 directions."
let caseList = CompassDirection.allCases
.map({ "\($0)" })
.joined(separator: ", ")
// caseList == "north, south, east, west"
[ 성공 하나 😊 ]
테스트 코드를 먼저 작성하고 red를 green으로 바꾸면서 구현했다.(RGR)
[ 결론 👩💻 ]
일단 만들어놓고 print 찍어봐야지 하는 생각보다는 이 테스트가 동작이 되게 해야겠다는 식의 목표가 있는 접근이 좋았다. 다만 고민거리는 있었다. 테스트 함수는 여러 값 중에서 어떤 값을 테스트 하는 게 좋을지, 어디부터 어디까지 테스트해야 하는지. 앞으로 테스트 함수를 많이 짜봐야겠다.
[ 성공 둘 😊 ]
테스트 코드를 작성할 때 Given, When, Then을 나눠서 작성했다. (BDD)
[ 결론 👩💻 ]
생각나는 대로 짜는 것 보다 주어진 Given, When, Then에 맞춰서 구현하는게 편했다.
🧐❓: 테스트 함수는 여러 값 중에서 어떤 값을 테스트 하는 게 좋을까, 어디부터 어디까지 테스트해야 할까?
😁 ❗️
... 찾아서 업데이트 할 예정.
🧐❓: Dictionary나 Class, Struct, enum 데이터 구조가 갖는 각각의 장점은 뭘까? 각각의 선택 기준은 뭘까?
😁 ❗️
... 찾아서 업데이트 할 예정.
iOS 관련 문법은 애플 공식문서를 보는게 최고다.
프로토콜은 알면 알수록 도움된다. 다다익선.
알맞는 프로토콜을 채택할 수 있는게 중요한 것 같다.
테스트 코드도 생각보다 고민이 많이 필요한 부분이다.
내일 열심히 해야겠다.
취미가 필요하다.