말랑한 하루

이 테스트는 상태관리를 검증하는 역할을 수행합니다. 상태관리를 검증하는 이유는, 코드의 동작을 확인하고 안정성을 보장하여 예측 가능한 애플리케이션을 만들어가기 위해서 진행합니다. 🍒 Notifier 구현 Riverpod의 Notifier를 활용한 상태관리를 구현하는 부분을 추가합니다. Notifier는 TodoUseCase를 활용하여 Todo데이터를 State에 저장하고 관리합니다. final todoProvider = StateNotifierProvider((ref) { final todoUseCase = ref.read(todoUseCaseProvider); return TodoNotifier(todoUseCase: todoUseCase); }); class TodoNotifier extends St..

Clean Architecture에서 UseCase는 Repository를 활용하여 실질적인 비즈니스 로직을 구현하는 것에 초점을 맞추고 있습니다. UseCase Test는 결과를 잘 가져오는지 그리고 MockRepository를 활용한 결과 값과 UseCase의 결과 값이 같은지 비교합니다. 🍒 객체 선언 및 초기화 class MockTodoRepository extends Mock implements TodoRepository {} void main() { late TodoUseCase todoUseCase; late MockTodoRepository mockTodoRepository; setUp(() { mockTodoRepository = MockTodoRepository(); usecase = ..

이 테스트는 data폴더에서 구현한 todo_repository를 검증하는 역할을 수행합니다. repository는 가장 바깥쪽 계층인 Driver, 즉 외부 API와 통신하는 DataSource의 의존성을 주입 받기 때문에, UseCase 🍒 객체 선언 및 초기화 class MockTodoRemoteDataSource extends Mock implements TodoRemoteDataSource {} void main() { late TodoRepository repository; late MockTodoRemoteDataSource mockRemoteDataSource; setUp(() { mockRemoteDataSource = MockTodoRemoteDataSource(); repository..

※ 글의 순서는 🐇>🥕>🍒>🍇>🍌>🍏 순서로 하위 내용을 구성하고 있습니다. DataSource는 외부 API와 통신을 진행하는 Framework & Driver 계층에 속합니다. 이 계층에서는 HTTP 통신에 대한 객체 생성과 관리, 요청에 대한 테스트 진행 방법에 대해 기술하려 합니다. 🥕 todo_remote_data_source_test 이 테스트는 TodoList를 구현할 때, HTTP 통신을 위한 Dio 라이브러리를 활용하여 외부 API와 통신하는 TodoRemoteDataSource Class의 메소드를 검증하는 역할을 수행합니다. 🍒 객체 선언 및 초기화 🍇 Create Mock Object of HTTP Client 네트워크 요청을 시뮬레이션 하기 위해서 먼저, DataSource Cla..

Test Driven Development라 불리는 소프트웨어 개발 방법론 중 하나 입니다. 개발자가 코드를 작성하기 전에 테스트 케이스를 먼저 작성하고, 그 후에 해당 테스트 케이스를 통과하는 코드를 작성하는 방식으로 진행됩니다. 진행 과정은 다음과 같습니다. 🍒 Test: 테스트 작성 새로운 기능이나 수정된 기능에 대한 테스트 케이스를 작성합니다. 이 테스트는 아직 구현되지 않은 기능이나 버그가 있는 부분을 검증하는 역할을 합니다. 🍒 Fail: 테스트 실패 작성한 테스트가 현재 코드에서 실패하도록 만듭니다. 아직 구현되지 않았기 때문에 당연한 결과입니다. 🍒 Code: 코드 작성 실패한 테스트 코드가 통과하도록 재 작성합니다. 목표는 테스트를 통과하는 최소한의 코드를 작성하는 것입니다. 🍒 Pass..

Model, View, ViewModel로 구성하는 소프트웨어 아키텍처 디자인 패턴입니다. 사용자 인터페이스(UI)와 비즈니스 로직을 효과적으로 분리하기 위해 사용됩니다. MVVM 디자인 패턴의 가장 큰 특징은 양방향 데이터 바인딩 방식에 있습니다. Model의 변화가 자동으로 View에 반영되고, View의 사용자 입력이 자동으로 ViewModel과 Model에 전달되어 일관된 상태를 유지할 수 있습니다. 그럼으로써, 코드의 재사용성과 유지보수성을 향상시킬 수 있습니다. 또한, ViewModel의 재사용성으로 인해 코드 중복을 최소화 하고 모듈성을 증가시킬 수 있습니다. ViewModel은 View와 Model의 중간 매개체로서 비즈니스 로직에 대한 단위 테스트에 용이합니다. 덕분에 View 또한, U..

🐇 Clean Architecture? Robert C. Martin이 제시한 아키텍처 패턴입니다. 소프트웨어 시스템을 독립적인 계층으로 분리하고, 각 계층 간의 의존성을 최소화하여 유지보수성, 테스트 용이성, 확장성을 향상시키기 위해 만들어 졌습니다. 🐇 계층 소프트웨어 시스템을 안정적이고 유연하며 변화에 적응하기 쉽게 만드는 것을 목표로 Entity, Use Case, Interface Adapter, Framework and Drivers 계층으로 구성되어 있습니다. 🍒 Entity 핵심 비즈니스 규칙과 데이터를 포함하는 가장 안쪽 계층입니다. 애플리케이션의 핵심 데이터 구조를 포함하고 있습니다. 🍒 Use Case 비즈니스 규칙과 로직을 구현하는 계층입니다. Entity에 접근하여 특정 비즈니스 ..

간단하게 통과할 줄 알았던 애플리케이션이 비공개 테스트 진행을 거부 받았다. 관련된 내용은 정책 적용 범위 정책 위반이었다. 🐇 정책 적용 범위 정책 위반 앱의 스토어 등록정보에 사용 권한이 없을 수 있는 단어, 문구, 이미지, 동영상이 포함되어 있는 것 같습니다. 앱의 스토어 목록에서 이 문제가 식별된 위치에 대한 자세한 내용은 아래의 '문제 세부정보'를 참조하세요. 나는 설명 문구 란에 포함되면 안되는 단어가 포함된 것 같다. 그 문구가 무엇인지는 정확하게 통보되지 않았다. 하지만 문제에 대한 해결을 진행하는 방법은 두 가지로 추가 제시해주었기 때문에 그 방법을 따라가려 해본다. 🥕 앱이 규정을 준수하도록 하려면 다음 단계를 따르세요 이 콘텐츠 사용 허가에 관한 서면 문서를 제출한 경우 사전 통지 양..