TDD는 매우 짧은 개발 사이클을 반복하는 software 개발 프로세스 중 하나이다.

TDD와 기존 개발 프로세스의 차이점

TDD의 3가지 절차

Red(실패): Writing a Failing test

TDD 개발에서의 첫번째 단계는 실패이다. 즉 실패하는 테스트 케이스를 작성하는 것이다. 이때 테스트케이스는 프로젝트 전체의 모든 기능에 대해서 모든 케이스를 작성하는 것이 아니라, 먼저 구현할 기능에 대새서 테스트 케이스를 하나씩 작성해 나가는 것이다.

Green(성공): Write just enough code to pass it

두번째 단계는 성공이다. 실패 단계에서 작성한 테스트 케이스를 통과 시키기 위한 최소한의 코드를 작성하는 단계이다.

Blue(리팩토링): Change code for better without chaning the behavior

세번째 단계는 리팩토링이다. 성공단계에서 작성한 코드에 중복되는 코드나, 개선시킬 방법이 있다면 리팩토링을 진행해둔자. 리팩토링을 진행하면서 매 단계마다 테스트 케이스를 통과하는지 확인해야한다. 이 단계까지 구현이 완료되었다면 다시 첫번째 단계로 새로운 실패하는 테스트 케이스를 작성하면 된다.

TDD의 장점

1. 객체지향적인 코드 개발

   테스트 코드를 먼저 작성하면 명확한 기능과 구조를 설계할 수 있다. 또한 TDD프로세스를 따르는 코드의 경우에는 재사용성을 고려하며 작성하게 된다.

2. 설계 수정 시간의 단축

   테스트를 먼저 해보기 때문에 걸계의 구조적인 문제를 바로 찾아날 수 있게 된다.

3. 디버깅 시간의 단축

   단위 테스트 기반의 테스트 코드를 작성 → 문제 지점을 쉽게 발견

4. 유지 보수의 용이성

   자동화된 유닛 테스팅을 전재 → 테스트 기간 ↘️

5. 테스트 문서의 대체 가능

   테스팅을 자동화 && 테스트의 근거를 산출할 수 있다.

단위테스트(Unit Test)

단위테스트(Unit Test)는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차이다.

단위테스트 장점

• 문제점 발견 → 프로그램의 각 모듈들을 고립시켜서 각각의 부분들이 정확하게 동작하는지 확인하는 것이다.
• 변경이 쉽다 → ****Unit Test를 믿고 regectoring을 언제든지 할 수 있고, 변경후에 해당 모듈이 잘 작동하는지 확인하는 unit test인 회귀 테스트를 통해서 변경된 모듈을 확인할 수 있다.
• 통합이 간단 → 유닛 자체의 불확실성을 제거해주므로 bottom-up(상향식) 테스트 방식에서 유용하다. 각 모듈을 검증하고 모듈들을 합쳐서 다시 검증하는 통합 테스트에서 더욱 효율적이다.

단위테스트는 어떻게 작성해야할까?

FIRST - 테스트에 대한 모법 사례(Best Pracices for testing)

• Fast(빠르게) : 테스트는 빠르게 실행되어야 한다.
• Isolated / Independent(분리된 / 독립적인) : 테스트는 따로 설정이나 분리를 해서는 안된다.
• Repeatable(반복가능한) : 테스트 수행할 때 마다 동일한 결과를 얻어야 한다. 외부의 데이터 공급자나 동시성 문제로 인해 일시적 오류는 발생할 수 있다.
• Self-validating(자체 검증) : 테스트는 완전히 자동화 되어야 한다. 로그 파일에 대한 프로그램의 해석보단 “pass” or “fail” 출력
• Timely(적시에) : 이상적인 테스트는 테스트한 생산 코드를 작성하기 전에 작성해야한다.

단위테스트는 무엇을 테스트 해야할까?

Right - BICEP

Right - 결과가 올바른가?

• Boundary : 모든 경계 조건이 correct 한가? (경계값들의 조건)
• Inverse : 역 관계를 확인할 수 있는가?
• Cross-Check : 다른 수단을 사용해서 결과를 교차할 수 있나?
• Error Condition : 에러 조건을 강제로 만들 수 있나?
• Performance : 성능 특성이 한도내에 있나?

이상 공부 끝

동기는 말 그대로 동시에 일어난다는 뜻입니다.

요청과 그 결과가 동시에 일어난다는 약속인데요. 바로 요청을 하면 시간이 얼마나 걸리던지 요청한 자리에서 결과가 주어져야 합니다.

• 요청과 결과가 한자리에서 동시에 일어남
• A노드와 B노드 사이의 작업 처리 단위(transaction)를 동시에 맞추겠다.
• 동기 방식은 서버에서 요청을 보냈을 때 응답이 돌아와야 다음 동작을 수행할 수 있다. 즉 A작업이 모두 진행 될때까지 B작업은 대기해야 한다.

비동기(Asynchronous : 동시에 일어나지 않는)

비동기는 동시에 일어나지 않는다를 의미합니다.

요청과 결과가 동시에 일어나지 않을거라는 약속입니다.

• 요청한 그 자리에서 결과가 주어지지 않음
• 노드 사이의 작업 처리 단위를 동시에 맞추지 않아도 된다.
• 비동기 방식은 요청을 보냈을 때 응답 상태와 상관없이 다음 동작을 수행 할 수 있다. 즉 A작업이 시작하면 동시에 B작업이 실행된다. A작업은 결과값이 나오는대로 출력된다.

이미지

각각의 장점

동기

• 설계가 매우 간단하고 직관적이다

비동기

• 동기보다 복잡하다

각각의 단점

동기

• 결과가 주어질 때까지 아무것도 못하고 대기해야 한다.

비동기

• 결과가 주어지는데 시간이 걸리더라도 그 시간동안 다른 작업을 할 수 있으므로 자원을 효율적으로 사용할 수 있다.

예시

예를 들어. 나는 대학교에 있는 프린트집 사장이다. 나에게는 A, B, C, D 복사기 4대가 있다. 학생 2명이 나에게 300장짜리 복사를 맡겼다.

• 동기일 경우 : A복사기에 100장 복사를 시작했다. 근데, 다른 복사기를 사용할 수 없다. A복사기의 복사가 먼저 끝나야 하기 때문이다.
• 비동기일 경우 : A복사기에 100장 복사를 시작했다. A복사기의 복사가 끝나는 것에 상관없이 B, C복사기에도 100장 복사를 시작했다.

작업의 순서에만 집중해서 보면, 차이가 극명하게 보일 것이다.

동기는 설계가 간단하고 직관적이지만, 결과가 주어질 때 까지 대기를 해야하는 단점이 있고, 비동기는 설계는 복잡하지만 자원을 효율적으로 사용할 수 있다는 장점이 있다.

동기와 비동기의 개념을 이해했으면 Serial 과 Concurrent에 대해서도 알아보자.

직렬

분산처리 시킨 작업을 오직 한 개의 쓰레드에서만 처리하는 것이 직렬이다.

즉 A쓰레드에서 4개의 작업을 분산 처리 시켰는데, B스레드에서만 처리하는 것이다.

동시

몇개의 쓰레드로 분산할지는 시스템이 정하지만, 시스템이 정한 여러개의 쓰레그로 분산 처리하는 것이 동시이다.

작업들이 각자 독립적이지만 유사한 작업들일 때 굉장히 유용하다. (ex) 테이블뷰 셀 같은 것들을 서버에서 받아오는 것 )

의문들

1. 동시랑 비동기랑 비슷한 개념인가?
2. 직렬은 대체 왜 사용하지? 동시가 모든경우에 좋아 보인다.

비동기와 동시는 비슷해 보이지만 아예다른 개념이다

동기와 비동기는 메인 쓰레드에서 대기열을 어떤 방식으로 처리할지 정하는 것.

직렬과 동시는 어떤 대기열을 사용할 지 정하는 것

작동되는 개념이 비슷하다고 절대 혼용하지 말자. 아예 다른 개념이다.

직렬을 사용하는 이유

바로 작업의 '순서'가 중요할 때 직렬이 사용된다.

동시는 여러개의 쓰레그에서 분산 작업하기 때문에 순서를 상관하지 않고 쓰레드에 할당된 작업은 각 쓰레드가 모조리 처리한다. 따라서, 만약 어떤 작업이 꼭 먼저 이뤄져야 한다면, 그럴때는 직렬을 사용하는게 좋다.

프로그램의 성능/반응성 을 올리고 최적화를 하기 위해서 하는 것이 동시성 프로그래밍이다.

이런 에러가 떠서 바로 검색했더니 info.plist에 위에 친구들을 추가해주라고해서 바로 추가했더니 해결했다ㅏ.

참고

선배들이 작성한 코드를 pull 받아와서 빌드 해보려고 하는데 이게 뭐야

이친구가 두두등장 했다 바로 검색을 했다ㅏ.

검색해보니

pod 버전 쪽에 문제가 있어서 그냥 간단하게

sudo gem update cocoapods --pre
pod update

를 해주고 프로젝트 클린해주고 나면 에러 없이 정상빌드 되는것을 확인할 수 있다.

위 코드는 제가 프로젝트를 하면서 로그인 버튼을 만들때 쓴 코드 입니다. 저 코드에서 접근제어자는 fileprivate인데.. 습관적으로 적어서인지.. 정확히 private와 fileprivate의 차이를 알지 못하여서 공부해 보았습니다.

Swift에서의 접근 레벨(Access Levels)

Swift에서는 5개의 접근레벨을 제공하는데요

• Open & Public : Open과 Public 모두 선언한 모듈이 아닌 다른 모듈에서 사용할 수 있습니다. 이 둘의 차이점은 Open은 다른 모듈에서 오버라이딩과 서브클래싱이 가능하지만 Public은 불가능 합니다.
• Internal : 아무 접근레벨도 설정하지 않으면 Internal로 간주됩니다. 해당 모듈 전체에서 사용가능합니다.
• Fileprivate : 특정 엔티티를 선언한 클래스에서만 사용이 가능합니다.
• Private : 특정 엔티티가 선언된 괄호{}안에서만 사용이 가능합니다.
  

음.... 이해가 잘 되지 않는데 글만 잘 읽어 본다면 Open > Public > Internal > Fileprivate > Private 순으로 개방(?)적인 것을 알 수 있습니다ㅏ

여기서 저희가 자세히 볼 것은 Fileprivate와 Private이죠

Fileprivate와 Private

이제 정말 다왔는데 위 말이 너무 어렵죠...조금 쉬운 말로 한번 바꾼다면 어떻게 할 수 있을까요..?

일단 "Fileprivate는 같은 파일 안에서만 사용가능하다!" 라고 하면 조금 쉽죠 그럼 "Private는 같은 코드블럭 안에서만 사용가능하다!" 라고 생각하면 될거 같네요...

마무리...

오늘은 이렇게 Fileprivate와 Private의 차이점을 살펴봤는데... 이해가 쉽게 되지는 않네요... 나중에 꼭 몇번 더 봐야겠습니다..

개인적으로 생각을 정리하며 쓴 글이다보니 실수가 많을거 같은데 글을 읽다가 아 이건 틀렸는데? 싶은 것이 있다면 댓글로 꼭 알려주시면 감사하겠습니다!

참고 Swift Language Guide, [Swift] AccessControl (Bill Kim's Life), Swift) AccessControl (Zedd0202)

나중에 알고보니 Xcode에서 그냥 보이지만 않을뿐 존재는 하는것 같았다(SwiftLint를 사용하였는데 빌드하니 FileChanges 에는 변경사항이 있는것으로 나왔다.)

쨋든 그래서 나는 궁금해졌다. 폴더와 그룹의 차이는 무엇일까

차이점

일단 그룹은 실제 파일시스템 구조에 영향을 주지 않고 프로젝트의 파일을 구성할 수 있다. 하지만 리소스 파일에는 적합하지 않다. 폴더는 당연히 파일시스템 구조에 영향을 준다.

따라서 Xcode의 코드로만 작업할 것이라면 그룹이 좋을것이다.

출처 : 스택오버플로우

팀 프로젝트를 하다가 Class _PathPoint is implemented in both로 시작하는 로그가 찍히는 것을 보고 바로 검색했다.

검색을 해보니 Objective-C 런타임에서 _PathPoint 및 _PointQueue 둘중 하나를 지정해 주어야 한다고 알려주는 것이였다.

따라서 이건 그냥 단순한 로그 노이즈 라고 하니 무시하고 코딩을 하면 될 것 같다.

출처 : 스택오버플로우