안녕하세요!요즘 TDD를 위해 Swift의 Unit Test, UI Test를 학습하고 있었습니다그런데 UI Test 학습 중에 예상치 못한? 문제를 겪게 되었습니다 아래의 상황은 회원가입 버튼을 누른 후 Success Alert가 나와야 하는데,Error Alertr가 나와 Test가 실패했다는 내용입니다 저는 음? 싶었던 게 저기 내부 함수의 검증 동작들은 Unit Test에서 이미 다 통과가 되었었거든요그런데 UI Test에서 직접 입력을 동작시키니까 Fail이 뜬 겁니다그래서 Break를 걸어서 에러가 나오는 구간을 잡아봤습니다그랬더니 저기서 딱 걸리더라고요 그런데 passwordMinLength값이 8이고 테스트를 위한 값도 8자리 이상을 주었기 때문에테스트에 실패할 이유가 없는데....
안녕하세요! 요즘 TDD를 적용해보고 싶어 Unit Test를 학습하고 있는데요,본격적인 Unit Test 내용은 아직 정리가 안되어서 Unit Test 서론? 같은? 느낌으로 Unit Test에 왜 의존성 주입이 필요한지 이야기해보려고 합니다. 의존성 주입의 필요성예시 상황으로 회원가입을 하는 함수들을 Unit Test를 통해 검증받고 싶다고 해봅시다.대충 이런 상황입니다! 그러면 UnitTest 파일에서 ViewModel의 함수들을 알고 있어야 하니까ViewModel 전체를 소유해야 합니다 그런데 보통 ViewModel에는 다른 기능들도 많이 포함되어 있을 수 있어요예를 들어 회원 탈퇴 절차도 ViewModel에 있다고 해봅시다. 그럼 테스트를 원하지 않는 코드까지 몽땅 Unit Test..
ProjectWithGitAPI안녕하세요!이전에 혼자 Git API를 이용한 작은 프로젝트를 진행했습니다.당시에는 MVVM 아키텍처로 구현하려고 했는데....진행하다 보니 스스로 아키텍처 패턴에 대한 이해가 낮은 게 느껴지더라구요. 그래서 아키텍처 패턴을 다시 학습하고!동일한 기능을 다양한 아키텍처 패턴으로 구현하는 프로젝트를 진행하려고 합니다.(최대한 아키텍처 패턴을 준수하도록 신경 쓰면서 코드를 짰습니다.) 해당 프로젝트가 규모는 작아도 Rest API, 네트워킹, 이미지 Caching, 페이징 처리,외부 라이브러리 사용 등등 배웠던 기술들은 거의 다 적용되었습니다.그래서 ProjectWithGitAPI 라는 이름으로 아키텍처 패턴을 공부하기 위한 프로젝트로 채택하게 되었습니다.(MVVM 패턴 정리 ..
안녕하세요!보통 혼자 작은 작업을 할때는 세부 브랜치를 관리하기 보다TBD처럼 단일 브랜치를 관리하는게 편해서 자주 사용했었습니다. 하지만 프로젝트 규모가 큰 현업에서는 더 안정적인 브랜치 전략인Git-Flow 형식을 대부분 쓴다고 합니다. 그래서 이번에는 Git Flow 브랜치 전략에 대해 알아보고 실제로어떻게 적용했는지 이야기해보려고 합니다! 1. 브랜치의 종류- Main: 배포 가능한 상태의 코드가 있는 브랜치.- Develop: 개발된 작업이 모이는 개발 브랜치.- Feature: 개발 작업이 진행되는 작업 브랜치.- Release: 배포 준비를 위한 브랜치.- Hotfix: 빠른 버그 수정을 위한 브랜치. 이 중에서 Main과 Develop이 핵심 브랜치로 상시 존재하며나머지 브랜치는 상태 관리..
