🤓 오늘 배운 내용!

---

1. Queue / Stack

Queue와 Stack은 자료구조 종류이다.

Queue

선입선출, FIFO(First-In-First-Out) 방식
현실세계에서 은행업무, 놀이공원 줄서기가 선입선출에 해당된다.

먼저 들어온 데이터가 먼저 나가는 선입선출 방식이다.
큐에서 데이터가 들어오는 곳을 rear, 데이터가 나가는 곳을 front라고 한다.
큐의 rear에서 데이터를 삽입하는 연산을 enQueue, front에서 데이터를 삭제하는 연산을 deQueue라 한다.

Stack

후입선출, LIFO(Last-In-First-Out) 방식
현실세계에서 쌓아둔 접시를 위에서 부터 하나씩 빼는 것이 후입선출에 해당된다.

가장 마지막에 들어온 데이터가 먼저 나가는 후입선출 방식이다.
Queue와 달리 데이터가 들어오는 곳과 나가는 곳은 하나(top)이다. 즉, 통로가 하나이다.
top에서 데이터를 삽입하는 연산을 push, top에서 데이터를 삭제하는 연산을 pop이라 한다.

참고블로그 / 튜나 개발일지

2. Unit Test / TDD

Unit Test (단위 테스트)

소스코드의 특정 모듈이 의도된대로 정확히 작동하는지 검증하는 절차

함수나 메서드에 대한 Test code를 작성해서 검증한다.
예를 들면, 과일로 쥬스를 만드는 메서드가 정상 작동하는지 검증하고 싶다.
그렇다면 "바나나 3개로 바나나 쥬스를 만든다"라는 case를 정의하고,
test code안에 case와 같은 상황을 셋팅한 후,
내가 검증하고 싶은 메서드를 호출하는 방식이다. 그러면 test case는 test에 대한 결과를 알려준다.

👾 How to?

1. 프로젝트에서 새로운 Target을 만든다.

Unit Test Bundle 템플릿으로 생성한다.
보통 테스트 이름은 "프로젝트명+test"

2. 프로젝트의 Test에 Test Target을 추가한다.

프로젝트 코드를 어떤 test로 테스트할지 설정해주는 과정이다.
command + shift + , 또는 Edit Schemes에서 연결한다.(Command Line Tool에서도 가능)



3. Target Membership 맺기
test하려는 소스코드로 가서 [Target Membership]에서 JuiceMakertest를 체크한다.
JuiceMaker.swift를 빌드할 때 JuiceMakertest도 함께 컴파일하게 하겠다는 의미이다.

Target Membership
Target Membership에서 체크된 target은 target을 build할 때 compile할 파일에 포함된다.

????????? 반대 아닌가?????????

4. test메서드를 클래스안에 작성한다.

메서드명은 꼭 test로 시작해야한다.

import XCTest

class IntStackTests: XCTestCase {
    func test_바나나_3개로_바나나쥬스를_만든다() {
        // test code 작성
        let maker = JuiceMaker()
        let result = maker.makeJuice(fruit: .banana, amount: 3)
        XCTAssertEqual(result, .success(.banana))
    }
 }

5. test를 실행한다.
edge case를 만들어 체크해주면 더 정확하게 검증할 수 있다.

Test Case

요구사항, 구현해야할 기능을 분석한 다음 작성한다.

각각의 case는 서로 영향을 주고 받으면 안된다. 독립적이어야 한다.

TDD (테스트 주도 개발)

소프트웨어 개발 프로세스 중 하나.

1) 요구사항에 대한 실패할 test case를 먼저 작성하고,
2) 그 다음 test case를 통과하기 위한 최소한의 프로덕션 코드를 작성한다.
3) 마지막으로 작성한 코드를 리팩토링한다.

TDD Cycle

[출처] https://www.thinktocode.com/2018/02/05/what-is-tdd/

compile error또한 failure, 실패한 test case로 간주 할 수 있다.

TDD의 좋은 점

• 요구사항을 이해하고 있어야만 test code를 작성할 수 있다. 요구사항을 정확하게 잘 파악할 수 있도록 돕는다.
• 코드를 검증하기 쉽다. 테스트가 가능한 코드로 작성하게 된다.
• 테스트가 코드를 설명하는 문서가 될 수 있다.
• 코드를 변경하는데 두려움을 없앨 수 있다(?)
• 결합도를 낮출 수 있다.
• 디버깅 시간을 줄 일 수 있다.
  
  

+ Result Type

Result
A value that represents either a success or a failure, including an associated value in each case.

Generic Enumeration으로, success또는 failure를 표현할 수 있는 값이다. 각 케이스에 연관 값을 가질 수 있다.

@frozen enum Result<Success, Failure> where Failure : Error

3. UIStepper

stepper의 + - 버튼으로 value를 증감시킬 수 있다.

🧐 궁금한 점

---

1. 스토리보드 UI의 view 반영 시점

두번째 화면 viewcontroller의 인스턴스를 첫번째 화면에서 생성하고, 인스턴스의 UILabel을 변경해준다음 두번째 화면으로 전환하려고 했다. 그런데 두번째 화면을 띄웠더니 첫번째 화면에서 변경해준 UILabel이 반영되지 않았다.

스트리보드 UI는 viewDidLoad()에서 로드된다. 따라서 첫번째 뷰 컨트롤러에서 UILabel에 접근을 할 수가 없고, UILabel에 값을 변경해줘도, viewDidLoad()가 호출되면서 스토리보드UI로 초기화가 된다.