플러터로 앱 만들기 플러터로 앱 만들기

테스트 환경에서 위젯을 찾으려면 Finder 클래스를 사용하세요. 직접 Finder 클래스를 작성할 수도 있지만, 일반적으로는 flutter_test 패키지에서 제공하는 도구들을 사용하는 것이 더 편리합니다.flutter run 명령으로 위젯 테스트를 실행 중일 때는, 화면의 일부를 인터랙티브 하게 탭 하면 Flutter 도구가 권장 Finder를 출력해주기도 합니다.이 레시피에서는 flutter_test 패키지에서 제공하는 find 상수를 살펴보고, 이 상수가 제공하는 몇 가지 Finder를 사용하는 방법을 설명합니다. 사용 가능한 Finder 전체 목록은 CommonFinders 문서를 참고하세요.Finder 클래스의 역할이나 위젯 테스트에 익숙하지 않다면, 먼저 위젯 테스트 소개 레시피를 확인해보세..

위젯 클래스를 테스트하려면, Flutter SDK에 포함되어 있는 flutter_test 패키지에서 제공하는 몇 가지 추가 도구가 필요합니다. flutter_test 패키지는 위젯 테스트를 위해 다음과 같은 도구들을 제공합니다:WidgetTester는 테스트 환경에서 위젯을 빌드하고 상호작용할 수 있게 해줍니다. testWidgets() 함수는 각 테스트 케이스마다 새로운 WidgetTester를 자동으로 생성하며, 일반적인 test() 함수 대신 사용됩니다. Finder 클래스들은 테스트 환경에서 위젯을 찾는 데 사용됩니다. 위젯 전용 Matcher 상수들은 Finder가 테스트 환경에서 위젯 하나 또는 여러 개를 찾았는지 확인하는 데 도움이 됩니다. 이 모든 것이 벅차게 느껴진다면 걱정하지 마세요. ..

단위 테스트에서 실제 웹 서비스나 데이터베이스에서 데이터를 가져오는 클래스에 의존할 때가 있습니다. 하지만 이렇게 하면 몇 가지 문제가 발생할 수 있습니다:실제 서비스나 데이터베이스를 호출하면 테스트 실행 속도가 느려집니다.웹 서비스나 데이터베이스가 예상치 못한 결과를 반환하면 통과하던 테스트가 실패할 수 있습니다.이를 '불안정한 테스트(flaky test)'라고 합니다.실제 서비스나 데이터베이스를 사용하면 모든 성공 및 실패 시나리오를 테스트하기 어렵습니다.따라서 실제 웹 서비스나 데이터베이스에 의존하는 대신, 이러한 의존성을 "모킹(mock)"하는 것이 좋습니다. 모킹은 실제 웹 서비스나 데이터베이스를 흉내 내어 상황에 따라 특정 결과를 반환할 수 있게 합니다. 일반적으로 클래스를 대체할 다른 클래스..

앱에 기능이 많아질수록 수동으로 테스트하기 어려워집니다. 자동화된 테스트는 기능과 버그 수정 속도를 유지하면서 앱이 배포되기 전에 올바르게 작동하는지 확인하는 데 도움을 줍니다. 자동화된 테스트는 몇 가지 범주로 나뉩니다:단위 테스트(unit test): 단일 함수, 메서드 또는 클래스를 테스트합니다.위젯 테스트(widget test): 단일 위젯을 테스트합니다. (다른 UI 프레임워크에서는 컴포넌트 테스트라고도 합니다.)통합 테스트(integration test): 전체 앱 또는 앱의 큰 부분을 테스트합니다. 일반적으로 잘 테스트된 앱은 코드 커버리지를 통해 많은 단위 테스트와 위젯 테스트를 추적하며, 중요한 사용 사례를 모두 다룰 수 있는 충분한 통합 테스트를 포함합니다. 이는 아래에서 볼 수 있는 ..

위젯 클래스를 테스트하려면, Flutter SDK에 포함되어 있는 flutter_test 패키지에서 제공하는 몇 가지 추가 도구가 필요합니다. flutter_test 패키지는 위젯 테스트를 위해 다음과 같은 도구들을 제공합니다:WidgetTester는 테스트 환경에서 위젯을 빌드하고 상호작용할 수 있게 해 줍니다. testWidgets() 함수는 각 테스트 케이스마다 새로운 WidgetTester를 자동으로 생성하며, 일반적인 test() 함수 대신 사용됩니다. Finder 클래스들은 테스트 환경에서 위젯을 찾는 데 사용됩니다. 위젯 전용 Matcher 상수들은 Finder가 테스트 환경에서 위젯 하나 또는 여러 개를 찾았는지 확인하는 데 도움이 됩니다. 이 모든 것이 벅차게 느껴진다면 걱정하지 마세요...

UI 계층 테스트하기아키텍처가 잘 설계되었는지를 판단하는 한 가지 방법은 테스트하기가 얼마나 쉬운지를 보는 것이다. 뷰모델과 뷰는 입력값이 명확하게 정의되어 있기 때문에 그 의존성을 쉽게 모킹(mock)하거나 페이킹(fake)할 수 있으며, 유닛 테스트도 쉽게 작성할 수 있다. ViewModel 유닛 테스트뷰모델의 유일한 의존성은 리포지토리(또는 유즈케이스)이며, 리포지토리를 모킹하거나 페이킹하는 것이 유일한 사전 작업이다. 다음 테스트 예제에서는 FakeBookingRepository라는 페이크 객체를 사용한다.// home_screen_test.dartvoid main() { group('HomeViewModel tests', () { test('Load bookings', () { ..

앱 아키텍처에서 각 구성 요소는 명확한 통신 규칙을 따라야 한다.구성 요소가 다른 구성 요소와 통신할 수 있는가?구성 요소는 서로에게 무엇을 출력으로 노출하는가?특정 계층은 다른 계층과 어떻게 연결되어 있는가? 구성 요소 간의 의존성을 깔끔하게 유지하기 위해 아래 규칙이 적용된다:View - 오직 하나의 ViewModel만 알고 있음. 다른 레이어는 모름.ViewModel - 자신과 연결된 View는 알 필요 없음. 하지만 여러 Repository를 알고 있음.Repository - 여러 Service를 사용할 수 있음. 하지만 ViewModel에 대해서는 모름.Service - 여러 Repository에서 사용 가능, 하지만 Repository를 알지 못함.즉, 의존성은 아래 방향으로만 흐르고, 각 계..

데이터 계층데이터 계층은 앱의 ‘진실의 원천(source of truth)’ 역할을 함.모든 데이터는 이곳에서만 수정해야 함.외부 API와 통신하고, UI에 데이터를 제공하며, UI 이벤트에 따라 데이터를 수정하고 다시 API에 반영함. 구성 요소 2가지Repository (레포지토리)데이터의 진실된 상태를 유지사용자 이벤트에 따른 데이터 업데이트오프라인 기능을 지원할 경우 데이터 동기화, 재시도 로직 관리, 데이터 캐싱 등을 책임짐 Service (서비스)API(HTTP 서버 등)나 플러그인과 직접 통신하는 무상태 클래스부작용 없음, 순수하게 외부 데이터만 가져옴모든 외부 데이터는 반드시 서비스 클래스 내에서 가져와야 함 서비스 정의하기서비스는 무상태이며, 부작용이 없다. 오직 외부 API를 감싸는 역..