아기개발자의 성장일기

나는 아직 입장정리 안함. 테스트 코드에 대한 다양한 의견들을 모아두고 이러저러 써보고 결정할 것임. [1] 테스트 함수 네이밍 좋은 테스트 이름들 : 무엇을 테스트하고 있는지 명확합니다. 어떤 때 테스트가 통과하거나 실패하는지 명확합니다. 라고 생각하고 엄청 자세하게 테스트 이름을 짓는 파(?)가 있다. test2Add5WillBe7() 이런식으로...?! 또 이런 파 중에 스네이크케이스로 짓는 분들도 계시다 애플 WWDC 2019 Testing in Xcode 세션 데모에서는 그냥 이렇게 간단하게 테스트 함수 이름을 정했다. 간단 네이밍 파(?)가 있다 [2] 네트워크 Request를 테스트하느냐 안하느냐 오로지 더미데이터랑 Mock 객체들만 가지고 테스트하는 파(?)가 있다. 이런식으로 reques..

테스트 코드를 작성하는 최소한의 기준을 찾아가고 있는 과정 중이다. 예를 들어 얼마나 디테일하게 테스트해야하는지(테스트코드도 유지보수해야하기 때문에 너무 디테일하게 테스트 케이스를 생각해서 코드를 많이 짜는게 무조건 좋은 것만은 아닌 것 같구.. ), 꼭 테스트해야할 부분은 뭔지 등등 테스트 코드를 작성할 플랜을 짜는 것의 기준(?)이 될 만한 것들을 정리해나가자 :- ) [1] 애플의 Test Pyramid 올 해 뿐만 아니라 다른 해 발표에서도 Test Pyramid에 대해 많이 언급했다 테스트 피라미드란 이런 것인데, 피라미드 모델 접근법은 철저성, 품질 및 실행 속도 사이의 균형을 잡는 데 도움이 된다고 한다 (The pyramid model approach to testing helps to s..

https://github.com/Quick/Quick/blob/master/Documentation/ko-kr/QuickExamplesAndGroups.md Quick/Quick The Swift (and Objective-C) testing framework. Contribute to Quick/Quick development by creating an account on GitHub. github.com 여기서 너무 잘 설명해서 덧붙일 것도 없는 듯 하네용... Quick 감사합니다👏 한글번역 감사합니다👏 개인적으로는 테스트 메소드 이름이 엄청 구체적이여야한다고 해서 하나씩 만들때 마다 너무 긴데 잘 읽히나...? 이런 생각도 들고 약간의 귀찮음도 있었는데 Quick을 사용하면 긴 테스트 메소드 이..

Unit test 라이브러리로 많이 쓰이는 Quick과 Nimble..! 왜 유명한 것인지 Nimble부터 살펴보자 ☺️ [1] XCTAssert 와는 달리 매번 사용자 임의 실패 메시지를 지정할 필요가 없다 XCTAssert에서 실패 메세지를 작성해주지 않으면, XCTAssertTrue(contains(sillyMonkeys, kiki)) 테스트가 실패했을 때 달랑 "XCTAssertTrue failed" 이라는 실패메세지를 받게 된다 그래서 보통 이렇게 실패 메시지를 함께 작성한다 XCTAssertTrue(contains(sillyMonkeys, kiki), "Expected sillyMonkeys to contain 'Kiki'") 테스트가 실패했을 때 "Expected sillyMonkeys to..

https://ehdrjsdlzzzz.github.io/2019/05/24/RxSwift-7/ RxSwift (7) iOS를 공부하며 익힌 것을 기록합니다. ehdrjsdlzzzz.github.io Rx사이트에 있는 그림보다 여기 블로그 그림이 더 이해가 쉽다...! 설명도 좋다 감사합니다 👏 다만 throttle은 latest=true일때랑 false일때랑 그림이 없어서(true일때 그림만 있음...ㅠㅠ) 실험을 해보자~= [1] throttle latest = true 일때 [2] throttle latest = false 일때 결론은 latest가 true이면 trottle에서 지정해준 타이머가 끝나는 시점에 발행된 마지막 값을 가져오고 false면 안가져온다 그리고 debounce와 마찬가지로 t..

[1] 실패하는 테스트를 작성한다 10/2 = 5 인지 나눗셈 테스트 해보는 코드인데 당연히 실패한다. Calculator를 만들지도 않았기 때문에-! [2] 빨리 테스트가 통과하게끔 만든다. (또는 컴파일에러가 안나게 일단 막 만들 수 도 있는데 간단한 함수라 바로 구현함) [3] 이제 제대로 동작하는 지를 검사하겠다는 마인드를 지닌다. 다른 실패할 테스트를 만들어본다 (0으로 나눴을때) [4] 테스트가 통과하게끔 만든다 이런식으로 테스트 코드를 먼저 만들고 구현을 점진적으로 해나가는 것이 TDD의 느낌(?) 인 것 같다 그리고 테스트주도개발 에서 나온 것 처럼 일단 빨리 테스트를 통과하게 만들고 그 와중에 생겨난 중복제거 등 리팩토링을 마지막 단계로 해줄 수 도 있다 기능구현을 하고 테스트 코드를 뒤..

1. 빨강 - 실패하는 작은 테스트를 작성한다. 처음에는 컴파일조차 되지 않을 수 있다 2. 초록 - 빨리 테스트가 통과하게끔 만든다. 이를 위해 어떤 죄악을 저질러도 좋다 (죄악이란 기존 코드 복사해서 붙이기, 테스트만 간신히 통과할 수 있게끔 함수가 무조건 특정 상수를 반환하도록 구현하기 등을 의미한다) 3. 리팩토링 - 일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복을 제거한다 테스트를 먼저 작성한다는 것은 내가 상상하던 그 이상이였다 예제를 살펴보자 : ) [1] 정말 리얼 말그래도 테스트를 가장 먼저 작성한다 public void testMultiplication() { Dollar five = new Dollar(5); five.times(2); assertEquals(10, five...

테스트 코드부터 작성하는 것이 감이 안와서 테스트 코드보다 먼저 ArtistAPIService를 작성해버렸다... 🙄 이전 포스팅에서 만들었던 ArtistAPIType을 이용하여...!!! 물론 다음과 같이 Artist모델도 만들어줬다...!!! 그리고 Apple Music API 홈페이지에 들어가서 해당 API에 해당하는 더미데이터를 복붙하여 넣어준 더미데이터 파일을 만들고 테스트 코드 있는 쪽에 넣어준다 BananaMusicTests 그룹안에 넣어주면 된다 (나의 토이프로젝트 이름은 BananaMusic이기때문...ㅎㅎ!! ) 그리고 실제 서버에서 주는 데이터가 아니라 이 더미데이터를 파싱하는 ArtistAPIServiceStub 을 만든다 (Stub, Mock, Spy 등등 다양한 용어들이 있던데 ..

테스트 코드를 제대로 공부하고 싶어서 예제 프로젝트를 진행중이다 아직 유닛테스팅도 잘 작성하지 못하지만 TDD 어떤지 너무 궁금해서 해보기로 했다 :-) 띄엄띄엄 조금조금 공부중인데 흐름을 놓치지 않도록 잘 정리해서 기록해두자 주제는 Apple Music API를 이용한 토이 프로젝트...!!! Apple Music API는 이렇게 모든 API마다 response json을 친절하게 알려주는데, 이 json을 dummy data로 쓰기에 딱 좋기 때문이다 일단 Apple Music API를 사용하기 위해서는 developer token이 필요하다 이 순서대로 차근차근 해서 keyID, teamID 를 알아내고 나의 private key가 담긴 .p8 file을 얻어내야한다 https://developer..

Signal와 Driver는 UI 계의 PublishSubject / BehaviorSubject 같은 것...! Signal과 Driver 의 공통점 - error를 return 하지 않는다. - 메인 쓰레드에서의 작동을 보장한다. - Rxcocoa에 있음 Signal과 Driver 의 차이점 - Signal은 새로운 구독자에게 replay 해주지 않는다. (Driver 처럼 구독하는 순간 초기값이나 최신값을 주지 않는다. 구독한 이후에 발행되는 값을 받음. 위의 사진 참고) - Signal은 emit함수로 이벤트 처리 / Driver는 drive함수로 이벤트 처리 signal.emit(onNext: { (element) in } driver.drive(onNext: { (element) in } Rx..