Android

아무런 리소스 및 레퍼런스 없이 개발을 하는 프로젝트를 GreenField Project라고 한다. GreenField Project를 시작할 때 무엇을 먼저 하는 것이 좋을까? 가장 중요하고, 잘 변하지 않는 부분부터 공략한다. 기획자 혹은 비즈니스 부서와 함께 핵심 사용자의 시나리오를 설정하고, 핵심시나리오를 따라 코드를 옮겨 적는다. 이 때 최대한 데이터 및 UI와 같은 가변적인 요소는 배제하고, 애플리케이션의 핵심 로직, 재사용이 가능한 로직을 먼저 구현한다. 1. Domain Layer 도메인 계층은 Ui 계층에서 사용되는 비즈니스 로직을 캡슐화하여 모아놓은 곳이다. 인터페이스 형태로 존재하며, 실제 구현체는 숨겨져 있는 곳이다. 기획자 및 비개발군이 볼 수 있는 계층이며, 실제 비즈니스 로직이..

1. MVVM의 배경 기존의 패턴인 MVC, MVP의 경우 Model이 확실하게 독립적인 요소로 분리되었으나, View와 Controller, View와 Presenter의 의존성은 여전히 존재했다. 하지만 MVVM은 단방향 데이터 흐름을 가장 잘 구현할 수 있는 패턴으로, 단방향 데이터 흐름을 통해 View와 ViewModel 간의 의존성을 소거하였다. 단방향 데이터 흐름 상위 객체는 하위 객체의 상태를 읽을 수 없고, 하위객체로 이벤트를 보낼 수도 없다. 하위 객체는 상위 객체의 이벤트를 직접적으로 읽을 수 없다. MVVM에 대입하면, View는 사용자의 입력을 전달만 하고, 결과는 받지 않는다. 대신 간접적으로 상태 변경을 통보받는다. 2. MVVM의 구조 2 - 1. View View는 사용자에게..

안드로이드에서 앱을 설계할 때, 사용할 수 있는 다양한 패턴이 존재한다. MVC (Model - View - Controller) MVP (Model - View - Presenter) MVVM (Model - View - ViewModel) MVI (Model - View - Intent) etc 해당 패턴을 사용하는 이유는 여러가지 로직의 다분화와 클래스간의 의존성을 낮추는데에 있으며, 해당 과정을 통해 유지보수성과 테스트 가능성을 높히고, 더 나아가 지속가능한 개발에 목적을 가지고 있다. UI 계층(MVx)의 대원칙 어떤 경우든 Model은 분리되어야 한다. Model은 데이터를 다루는 모든 비즈니스 로직을 처리하는 계층 View의 역할을 할 수 있는 한 최대한 분리시켜야 한다. Android에서 ..

안드로이드 통합 테스트 소개 통합 테스트는 여러개의 클래스와 메소드를 모아 의도대로 수행하는지 확인하고, 다른 모듈과의 상호작용이 잘 이루어지는지 확인한다. (아래에 통합Ui테스트를 편의상 통합 테스트로 명시하였음.) 통합 테스트를 위해 아래와 같은 라이브러리를 추가 하였다. // Instrumentation tests androidTestImplementation 'com.google.dagger:hilt-android-testing:2.37' kaptAndroidTest 'com.google.dagger:hilt-android-compiler:2.37' androidTestImplementation "junit:junit:4.13.2" androidTestImplementation "org.jetbr..

안드로이드 유닛 테스트 소개 유닛 테스트는 소프트웨어에서 독립적으로 실행될 수 있는 가장 작은 부분 (함수, 메소드)와 같은 부분을 테스트 하는 것이다. 안드로이드에서 제공하는 유닛 테스트 라이브러리는 아래와 같다. // Local unit tests testImplementation "androidx.test:core:1.4.0" testImplementation "junit:junit:4.13.2" testImplementation "androidx.arch.core:core-testing:2.1.0" testImplementation "org.jetbrains.kotlinx:kotlinx-coroutines-test:1.5.1" testImplementation "com.google.truth:tr..

아키텍처에서 왜 테스트가 중요할까? 현실적인 필요성 QA보다 더 생산적으로 일할 수 있다. 앱이 확장될 수록 QA로 확인할 수 없는 다양성이 존재할 수 있다. 테스트 없이 결과를 확인하기 위해 로그 및 디버깅 작업은 비용이 큰 작업 좋은 설계를 촉진한다. 단일 책임 원칙, 개방 폐쇄 원칙을 위배하고 있는 클래스는 테스트하기 힘들기 떄문에, 테스트를 위해 해당 원칙을 준수해야 한다. 코딩 생산성 Fail 되지 않은 코드가 잘 움직이고 있다는 심리적 안정성이 코드에 집중할 수 있게 한다. 실제로 테스팅 구현을 함께하면 개발 시간이 짧아 진다. 협업을 촉진한다. 효율적인 코드 리뷰가 가능하다. 문서로서의 테스트 코드는 특정 API의 기능, 원작자의 의도를 확인할 수 있다. 코드 담당자가 아니라도 테스트 코드 ..