Forem: CodingMountain

Publish and upgrade your Flutter Package on pub.dev

Safal Shrestha — Mon, 09 Jan 2023 11:04:11 +0000

You are developing your awesome flutter app implementation awesome functionalities and awesome widgets. Now you want to share that awesomeness with others.

How do you do so?

Of course. By publishing your own awesome widgets as a package.

But how do you do so?

In this article, I want to show how to create and publish a package in “pub.dev ”.

First, pick a name for your package, mine will be **hello_world **which will return a container with the text “Hello World”. Then run

flutter create --template=package hello_world

in your terminal. It will create a template for your package in my case hello_world. In the template, you will find different files. Let’s look at some of them:

CHANGELOG.md: Here you will write the changes you made/added to the project. It is a record of changes for tracking your package and its version. It will appear in the changelog of your package.
LICENSE: You can add your license here.
pubspec.yaml: Your package dependencies go here.
README.md: It will appear in the Readme of your package. It can contain brief summary of your package along with documentation, example, installation, and so on.
lib: It is where you will write your package

Now let’s write the package.

Inside the lib, we will find hello_world.dart. Inside you will find the template.

library hello_world;

/// A Calculator.
class Calculator {
  /// Returns [value] plus 1.
  int addOne(int value) => value + 1;
}

The library keyword is used to give the library a name, which can be used to reference it from other parts of the code.

Let’s write our package.

library hello_world;

import 'package:flutter/material.dart';

class HelloWorld extends StatelessWidget {
  const HelloWorld({super.key});

  @override
  Widget build(BuildContext context) {
    return const Center(
      child: Text("Hello World!"),
    );
  }
}

Oh, and let’s initialize a Git repo in our project which helps when we need to publish our package.

Now we are ready to publish our package. Right?

Wrong. Before publishing the package, we still go something left to do. First, let’s organize our code.

We will create a new folder *lib/src *and put our implementation/widget there.

You can have any folder structure, but it is recommended to use lib/src . [source](https://dart.dev/guides/libraries/create-library-packages\)

After that our project will look like this.

We have moved out implementation code to hello.dart *inside *src.

E.g., hello.dart

import 'package:flutter/material.dart';

class HelloWorld extends StatelessWidget {
  const HelloWorld({super.key});

  @override
  Widget build(BuildContext context) {
    return const Center(
      child: Text("Hello World!"),
    );
  }
}

hello_world.dart is used as a barrel file to export our implementation.

E.g., hello_world.dart

library hello_world;

export "src/hello.dart";

A barrel file is a way to integrate multiple exports from different files into a single export.

Now our package is complete. Before publishing let’s add an example.

The example will contain a code from example/lib/main.dart. We haven’t yet created an example folder.

Let’s run the command:

flutter create example

After this, you will have a flutter project with a name example. Inside pubspec.yaml of example you can import your package in example with *path: ../ *instead of version.

E.g. example/pubspec.yaml

name: example
description: A new Flutter project.

publish_to: 'none'

version: 1.0.0+1

environment:
  sdk: '>=2.18.5 <3.0.0'

dependencies:
  flutter:
    sdk: flutter
  cupertino_icons: ^1.0.2
  hello_world:
    path: ../

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: ^2.0.0

flutter:
  uses-material-design: true

Now my lib/main.dart will be

E.g lib/main.dart

import 'package:flutter/material.dart';
import 'package:hello_world/hello_world.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'My Package'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key, required this.title});

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: const HelloWorld(),
    );
  }
}

This will be displayed in the example section of pub.dev of your package.

Now let’s change CHANGELOG.md

## 0.0.1

* Initial release of Hello World.

Now let’s write README.md

# Hello World
Gives Hello World widget

## Features
  - Hello world
  - Awesome
  - Null Safety

## Example Project
 Check the `example` folder

Now, let’s add a license to our package. You can use **this **website to help you choose your license.

MIT License

Copyright (c) 2022 Safal Shrestha

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

You can add the homepage and repository field to your pubspec.yaml .

Now run

flutter pub publish --dry-run

This command will analyze our package and warns us if there is any error/issues in our packages. After that, you can publish your package to pub.dev with the command:

flutter pub publish

Remember publishing is forever. After running the command, you will be asked to authenticate, and your package will be published after authenticating.

If you want to upgrade your package. Increase your package version and run flutter pub publish again.

In this post, you learned how to publish and upgrade your package. If you have any problem, you can reference my package here.
focus_widget_list | Flutter Package

Thanks for reading!

Learning TDD with Clean Architecture for Flutter Part IV

Safal Shrestha — Wed, 04 Jan 2023 15:51:00 +0000

Part I here
Part II here
Part III here

This is the final part of the series. Let’s get write into it.

Presentation Layer

It is the UI part. Code is written to give life to the app. It is the part where users interact. It consists of pages, widgets, and state management (bloc, provider, etc).

Pages

It consists of the screens to be displayed.

Widgets

It consists of the widgets that are being used.

Bloc

Let’s create a bloc for the movie list state management.

Eg. Movie Bloc lib/features/movie/presentation/bloc/movie_bloc.dart

import 'package:bloc/bloc.dart';
import 'package:equatable/equatable.dart';
import 'package:movie_show/core/usecases/usecase.dart';
import 'package:movie_show/features/movie/domain/entities/movie_entity.dart';
import 'package:movie_show/features/movie/domain/usecases/get_movie_list_usecase.dart';

part 'movie_event.dart';
part 'movie_state.dart';

class MovieBloc extends Bloc<MovieEvent, MovieState> {
  final GetMovieListUsecase getMovieListUsecase;

  MovieBloc({required this.getMovieListUsecase}) : super(MovieInitial()) {
    on<MovieEvent>((event, emit) async => await _onGetMovies(emit));
  }

  Future<void> _onGetMovies(Emitter<MovieState> emit) async {
    emit(MovieLoading());
    final failureOrMovieList = await getMovieListUsecase.call(NoParams());
    emit(failureOrMovieList.fold(
        (failure) => const Error(message: "Server Failure"),
        (movieList) => MovieLoaded(movieList: movieList)));
  }
}

Eg. Movie Bloc State lib/features/movie/presentation/bloc/movie_state.dart

part of 'movie_bloc.dart';

abstract class MovieState extends Equatable {
  const MovieState();

  @override
  List<Object> get props => [];
}

class MovieInitial extends MovieState {}

class MovieLoading extends MovieState {}

class MovieLoaded extends MovieState {
  final List<MovieEntity> movieList;
  const MovieLoaded({
    required this.movieList,
  });
  @override
  List<Object> get props => [movieList];
}

class Error extends MovieState {
  final String message;
  const Error({
    required this.message,
  });
  @override
  List<Object> get props => [message];
}

Eg. Movie Bloc Event lib/features/movie/presentation/bloc/movie_event.dart

part of 'movie_bloc.dart';

abstract class MovieEvent extends Equatable {
  const MovieEvent();

  @override
  List<Object> get props => [];
}

class GetMovies extends MovieEvent {}

After creating the bloc we will test it.

Eg. Movie Bloc test: test/features/movie/presentation/bloc/movie_bloc_test.dart

import 'package:dartz/dartz.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
import 'package:movie_show/core/error/failure.dart';
import 'package:movie_show/core/usecases/usecase.dart';
import 'package:movie_show/features/movie/domain/entities/movie_entity.dart';
import 'package:movie_show/features/movie/domain/usecases/get_movie_list_usecase.dart';
import 'package:movie_show/features/movie/presentation/bloc/movie_bloc.dart';

class MockGetMovieListUsecase extends Mock implements GetMovieListUsecase {}

void main() {
  late MovieBloc movieBloc;
  late MockGetMovieListUsecase mockGetMovieListUsecase;
  final tMovieList = [
    const MovieEntity(
      movieId: 'movieId',
      title: 'title',
      thumbnail: 'thumbnail',
      movieUrl: 'movieUrl',
      unlocked: true,
    ),
    const MovieEntity(
      movieId: 'moviesIds',
      title: 'titles',
      thumbnail: 'thumbnails',
      movieUrl: 'movieUrls',
      unlocked: false,
    )
  ];
  setUp(() {
    mockGetMovieListUsecase = MockGetMovieListUsecase();
    movieBloc = MovieBloc(getMovieListUsecase: mockGetMovieListUsecase);
  });
  group('Bloc Test', () {
    test('initial state should be MovieInitial()', () async {
      //Arrange
      //Act
      //Assert
      expect(movieBloc.state, equals(MovieInitial()));
    });
    test('should get data from usecase', () async {
      //Arrange
      when(
        () => mockGetMovieListUsecase.call(NoParams()),
      ).thenAnswer((_) async => Right(tMovieList));
      //Act
      movieBloc.add(GetMovies());
      await untilCalled(() => mockGetMovieListUsecase.call(NoParams()));
      //Assert
      verify(() => mockGetMovieListUsecase.call(NoParams()));
    });
    test('should emit MovieLoaded when data is obtained succesfully', () async {
      //Arrange
      when(
        () => mockGetMovieListUsecase.call(NoParams()),
      ).thenAnswer((_) async => Right(tMovieList));
//Assert Later
      final expected = [
        MovieLoading(),
        MovieLoaded(movieList: tMovieList),
      ];
      expectLater(movieBloc.stream, emitsInOrder(expected));
//Act
      movieBloc.add(GetMovies());
      // print(movieBloc.stream.runtimeType);
    });
    test('should emit Error when getting data fails', () async {
      //Arrange
      when(
        () => mockGetMovieListUsecase.call(NoParams()),
      ).thenAnswer((_) async => Left(ServerFailure()));
//Assert Later
      final expected = [
        MovieLoading(),
        const Error(message: 'Server Failure'),
      ];
      expectLater(movieBloc.stream, emitsInOrder(expected));
//Act
      movieBloc.add(GetMovies());
      // print(movieBloc.stream.runtimeType);
    });
  });
}

First, we test the initial state of the bloc. During the GetMovies() event the bloc should emit two states MovieInitial() and MovieLoaded() or MovieLoading() or Error(). The state of the bloc is obtained as a stream. Here we are using the expectLater() as the bloc is executing later. So we should keep on listening for the stream of state. What about the page and widget? Shouldn’t we test it? Here we are doing the unit test, in order to test those we need to do a widget test. That’s a topic for another time. Now let’s create the UI i.e. pages and widgets. Wait a minute there arises a problem. The presentation layer only knows about the domain layer. It doesn’t know about the data layer. There seems to be no connection between those. In the presentation, we are only calling the use-case and the use-case only contains the abstract function. The UI has no way to access implementation. With all the work we have done and we can’t connect those dots.

We can solve these issues by using dependency injection. It connects all the things we have been doing so far. So let’s connect the dots using get_it.

Let’s create a file injection_container.dart

Eg . lib/injection_container.dart

final sl = GetIt.instance;
Future<void> init() async {
//bloc
  // movie bloc
  sl.registerFactory<MovieBloc>(
    () => MovieBloc(
      getMovieListUsecase: sl(),
    ),
  );
//usecase

//movie use case
  sl.registerLazySingleton<GetMovieListUsecase>(
      () => GetMovieListUsecase(movieRepository: sl()));

//repository

// movie repository
  sl.registerLazySingleton<MovieRepository>(
    () => MovieRepositoryImpl(
      networkInfo: sl(),
      movieListRemoteDataSource: sl(),
      awsDataSource: sl(),
    ),
  );

//data sources

sl.registerLazySingleton<MovieListRemoteDataSource>(
    () => MovieListRemoteDataSourceImpl(provideFakeData: sl()),
  )

//core

//network info --> internet connected or not
  sl.registerLazySingleton<NetworkInfo>(
    () => NetworkInfoImpl(sl()),
  );
//fake Data
  sl.registerLazySingleton<ProvideFakeData>(() => ProvideFakeData());

//external
  final sharedPreferences = await SharedPreferences.getInstance();
  sl.registerLazySingleton<SharedPreferences>(
    () => sharedPreferences,
  );

sl.registerLazySingleton<Dio>(
    () => Dio(),
  );

sl.registerLazySingleton<Connectivity>(
    () => Connectivity(),
  );

}

The get_it package supports creating singletons and instance factories. Here, we’re going to register everything as required. We will register most of them as a singleton so that our app gets only one instance of the class per lifecycle except bloc which might need multiple instances.

To register, instantiate the class as usual and pass in sl() into every constructor parameter and define the constructor parameter in the same way and repeat until no constructor parameter is left.

Here we provide the implementation of the abstract classes should they appear in our code. Dependency injection was the missing link between the production and test codes, where we sort of injected the dependencies manually with mocked classes. Now that we’ve implemented the service locator, nothing can stop us from writing Flutter widgets which will utilize every bit of code we’ve written until now by showing a fully functional UI to the user.

Now you can initialize it in the main.dart file and start building your UI

Make sure to use the service locator that we created when accessing the bloc. To access movie bloc instance, you can use sl.

import 'package:flutter/material.dart';
import 'package:flutter/services.dart';
import 'injection_container.dart' as di;

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await di.init();
  runApp(
    const MyApp(),
  );
}

I won’t be doing the UI part. For reference go here and here(bloc)

Happy Coding!!

Learning TDD with Clean Architecture for Flutter (Data Layer) Part III

Safal Shrestha — Thu, 22 Sep 2022 04:57:09 +0000

Part I here

Part II here

Part IV here

In this part, let’s finish the data layer.

Data Layer

It is the layer in which the app interacts with the outside world. It provides data to the app from the outside. It consists of low-level Data sources, Repositories which are the single source of truth for the data, and finally Models.

Models

Models are the entity with some additional functionalities. The data from the outside mightn’t be in the format we desired. So, models interact with this harsh environment and convert the outside data to the entity. As the relationship between model and entity is very important, we should test if the models return the entity.

Eg. Movie Model Test test/features/movie/data/models/movie_model_test.dart

import 'dart:convert';
import 'package:flutter_test/flutter_test.dart';
import 'package:movie_show/features/movie/data/models/movie_model.dart';
import 'package:movie_show/features/movie/domain/entities/movie_entity.dart';

import '../../../../fixtures/fixture_reader.dart';

void main() {
  const tMovieModel = MovieModel(
    movieId:
        '''Big Buck Bunny tells the story of a giant rabbit with a heart bigger than himself. When one sunny day three rodents rudely harass him, something snaps... and the rabbit ain't no bunny anymore! In the typical cartoon tradition he prepares the nasty rodents a comical revenge.\n\nLicensed under the Creative Commons Attribution license\nhttp://[www.bigbuckbunny.org'''](http://www.bigbuckbunny.org'''),
    title: 'Big Buck Bunny',
    thumbnail: 'images/BigBuckBunny.jpg',
    movieUrl:
        "[http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4](http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4)",
    unlocked: true,
  );
  setUp(() {});
  test('MovieModel should be subclass of MovieEntity', () async {
//arrange
//act
//assert
    expect(tMovieModel, isA<MovieEntity>());
  });
  group('fromJson', () {
    test('should return a valid MovieModel', () async {
//Arrange
      final Map<String, dynamic> jsonMap =
          json.decode(await fixture('video.json'));
//Act
      final result = MovieModel.fromJson(jsonMap);
//Assert
      expect(result, tMovieModel);
    });
  });
  group('toJson', () {
    test('should return a JSON map from MovieModel', () async {
//Arrange
//Act
      final result = tMovieModel.toJson();
//Assert
      final expectedMap = {
        "movieId":
            "Big Buck Bunny tells the story of a giant rabbit with a heart bigger than himself. When one sunny day three rodents rudely harass him, something snaps... and the rabbit ain't no bunny anymore! In the typical cartoon tradition he prepares the nasty rodents a comical revenge.\n\nLicensed under the Creative Commons Attribution license\nhttp://[www.bigbuckbunny.org](http://www.bigbuckbunny.org)",
        "movieUrl":
            "[http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4](http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4)",
        "thumbnail": "images/BigBuckBunny.jpg",
        "title": "Big Buck Bunny",
        "unlocked": true
      };
      expect(result, expectedMap);
    });
  });
}

Json file has been used from here. You might be thinking why is movieID so long. It doesn’t matter here as we are just trying to learn here.

Here, we are writing multiple tests. A test can also be grouped together using a group.

At first, we make sure that the movie model extends from the movie entity and it returns the entity. Here we can see isA() keyword. It is used to check the type of object.

As our model interacts with the outside world and most of the data we get from the outside is in form of JSON, our model will have a function to convert this data to an entity. So, let’s write a test for fromjson and tojson.

As we are in the testing phase, let’s mimic those JSON responses.

Eg. Json responses test/fixtures/fixture_reader.dart

import 'dart:io';  
Future<String> fixture(String name) {   
   return Future.value(File('test/fixtures/$name').readAsStringSync()); 
}

Fixture reads from the JSON that we have created and returns them. Let’s look at our JSON file.

Eg. JSON file. test/fixtures/video.json

{
    "description": "Big Buck Bunny tells the story of a giant rabbit with a heart bigger than himself. When one sunny day three rodents rudely harass him, something snaps... and the rabbit ain't no bunny anymore! In the typical cartoon tradition he prepares the nasty rodents a comical revenge.\n\nLicensed under the Creative Commons Attribution license\nhttp://[www.bigbuckbunny.org](http://www.bigbuckbunny.org)",
    "sources": [
        "[http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4](http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4)"
    ],
    "subtitle": "By Blender Foundation",
    "thumb": "images/BigBuckBunny.jpg",
    "title": "Big Buck Bunny",
    "unlocked": true
}

In test/fixtures/video_list.json Copy json file from here

Wait a minute something seems wrong. It is not in the format where we defined the entity.

Should we go back and change the entity?

No, an entity is a rule that we cannot change (actually we can but we shouldn’t). The model is in charge of handling it, so the entity can get what it wants. If we run this test, the test fails (obviously as the model hasn’t been created yet), so let us write the model to make it pass.

Eg. Entity of Movie lib/features/movie/data/models/movie_model.dart

import '../../domain/entities/movie_entity.dart';

class MovieModel extends MovieEntity {
  const MovieModel(
      {required String movieId,
      required String title,
      required String thumbnail,
      required String movieUrl,
      required bool unlocked})
      : super(
            movieId: movieId,
            title: title,
            thumbnail: thumbnail,
            movieUrl: movieUrl,
            unlocked: unlocked);
  Map<String, dynamic> toJson() {
    return <String, dynamic>{
      'movieId': movieId,
      'title': title,
      'thumbnail': thumbnail,
      'movieUrl': movieUrl,
      'unlocked': unlocked,
    };
  }

factory MovieModel.fromJson(Map<String, dynamic> json) {
    return MovieModel(
      movieId: json['description'] as String,
      title: json['title'] as String,
      thumbnail: json['thumb'] as String,
      movieUrl: json['sources'][0] as String,
      unlocked: json['unlocked'] as bool,
    );
  }
}

In the model, you might see the super being used. This super is responsible to change the model into an entity (super passes the parameter to its parent constructor).

DataSources

Just like the name, they provide the data. They are the sources of data. There can be multiple data sources. For now, let’s go with a remote data source and create an interface for it.

Eg. movie data source. lib/features/movie/data/datasources/video_list_remote_datasource.dart

abstract class MovieListRemoteDataSource {
  /// Throws a [ServerException] for all error codes.
  Future<List<MovieModel>> getMovieList();
}

Now, let’s write a test.

Eg. Video List Remote DataSource Test. test/features/movie/data/datasources/video_list_datasource_test.dart

import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
import 'package:movie_show/core/error/exceptions.dart';
import 'package:movie_show/features/movie/data/datasources/video_list_remote_datasource.dart';
import 'package:movie_show/features/movie/data/models/movie_model.dart';
import 'package:movie_show/fixtures/fixture_reader.dart';

import '../../../../fixtures/fixture_reader.dart';

class MockMovie extends Mock implements MovieListRemoteDataSourceImpl {}

class MockProvideFakeData extends Mock implements ProvideFakeData {}

void main() {
  late MovieListRemoteDataSourceImpl movieListRemoteDataSourceImpl;
  late MockProvideFakeData mockProvideFakeData;
  setUp(() {
    mockProvideFakeData = MockProvideFakeData();
    movieListRemoteDataSourceImpl =
        MovieListRemoteDataSourceImpl(provideFakeData: mockProvideFakeData);
  });
  group('remote Data Source', () {
    test('should return list of movie model', () async {
      //Arrange
      when(() => mockProvideFakeData.fixture('video_list.json'))
          .thenAnswer((_) async => await fixture('video_list.json'));
      //Act
      final result = await movieListRemoteDataSourceImpl.getMovieList();
      //Assert
      verify(() => mockProvideFakeData.fixture('video_list.json'));
      expect(result, isA<List<MovieModel>>());
    });
    test('should return serverexception if caught', () async {
      //Arrange
      when(() => mockProvideFakeData.fixture('video_list.json'))
          .thenThrow(ServerException());
      //Act
      final result = movieListRemoteDataSourceImpl.getMovieList;
//Assert
      expect(() async => await result.call(),
          throwsA(const TypeMatcher<ServerException>()));
    });
  });
}

Where did the provide fake data come from? Remember data sources interact with the outside world, we are simulating the outside world with that class. When the function is supposed to throw an error, we should use thenthrow() and call a function throwsA() from the expect() function.

Eg. ProvideFake Data. lib/fixtures/fixture_reader.dart

import 'package:flutter/services.dart';
class ProvideFakeData {
  Future<String> fixture(String name) async {
// for a file
    return await rootBundle.loadString("assets/$name");
  }
}

Now let’s write the implementation of the data source so that the test can pass.

Eg. movie data source. lib/features/movie/data/datasources/video_list_remote_datasource.dart

// ignore_for_file: public_member_api_docs, sort_constructors_first
import 'dart:convert';

import '../../../../core/error/exceptions.dart';
import '../../../../fixtures/fixture_reader.dart';
import '../models/movie_model.dart';

abstract class MovieListRemoteDataSource {
  /// Throws a [ServerException] for all error codes.
  Future<List<MovieModel>> getMovieList();
}

class MovieListRemoteDataSourceImpl implements MovieListRemoteDataSource {
  final ProvideFakeData provideFakeData;
  MovieListRemoteDataSourceImpl({required this.provideFakeData});
  [@override](http://twitter.com/override)
  Future<List<MovieModel>> getMovieList() async {
    List<MovieModel> movieList = [];
    try {
      final jsonMap =
          json.decode(await provideFakeData.fixture('video_list.json'));
      final result = jsonMap['categories'][0]['videos'];
      for (var item in result) {
        movieList.add(MovieModel.fromJson(item));
      }
      return movieList;
    } catch (e) {
      throw ServerException();
    }
  }
}

After this, the test will pass.

Repositories

It is the brain of the model deciding what to do with the data obtained from the data sources. It is the implementation of the repository defined in the domain layer.

Before writing the test we create an abstraction for the dependencies that depend on the NetworkInfo.

Eg . Network Info. lib/core/network/network_info.dart

import 'package:connectivity/connectivity.dart';

abstract class NetworkInfo {
  Future<bool> get isConnected;
}

We don’t need to create the implementation of NetworkInfo as we are going to mock it (You can write implementation if you want but it won’t be used in the test). Now let’s write a test.

Eg . Repository Implementation test. test/features/movie/data/repositories/movie_repository_impl_test.dart

import 'package:dartz/dartz.dart';
import 'package:flutter_test/flutter_test.dart';
import 'package:mocktail/mocktail.dart';
import 'package:movie_show/core/error/exceptions.dart';
import 'package:movie_show/core/error/failure.dart';
import 'package:movie_show/core/network/network_info.dart';
import 'package:movie_show/features/movie/data/datasources/video_list_remote_datasource.dart';
import 'package:movie_show/features/movie/data/models/movie_model.dart';
import 'package:movie_show/features/movie/data/repositories/movie_repository_impl.dart';
import 'package:movie_show/features/movie/domain/entities/movie_entity.dart';

class MockRemoteDataSource extends Mock implements MovieListRemoteDataSource {}

class MockNetworkInfo extends Mock implements NetworkInfo {}

void main() {
  late MovieRepositoryImpl movieRepositoryImpl;
  late MockRemoteDataSource mockRemoteDataSource;
  late MockNetworkInfo mockNetworkInfo;
  final tMovieModelList = [
    const MovieModel(
      movieId: 'movieId',
      title: 'title',
      thumbnail: 'thumbnail',
      movieUrl: 'movieUrl',
      unlocked: true,
    ),
    const MovieModel(
      movieId: 'moviesIds',
      title: 'titles',
      thumbnail: 'thumbnails',
      movieUrl: 'movieUrls',
      unlocked: false,
    )
  ];
  final List<MovieEntity> tMovieEntityList = tMovieModelList;
  setUp(() {
    mockRemoteDataSource = MockRemoteDataSource();
    mockNetworkInfo = MockNetworkInfo();
    movieRepositoryImpl = MovieRepositoryImpl(
      networkInfo: mockNetworkInfo,
      movieListRemoteDataSource: mockRemoteDataSource,
    );
  });
  group('getMovieList:', () {
    test('should check if device is online', () async {
      //Arrange
      when(
        () => mockNetworkInfo.isConnected,
      ).thenAnswer((_) async => true);
      await mockNetworkInfo.isConnected;
//Assert
      verify(() => mockNetworkInfo.isConnected);
    });
    group('when device is online', () {
      setUp(() {
        when(
          () => mockNetworkInfo.isConnected,
        ).thenAnswer((_) async => true);
      });
      test('should return remote data when call is succesfull', () async {
        //Arrange
        when(
          () => mockRemoteDataSource.getMovieList(),
        ).thenAnswer((_) async => tMovieModelList);
        //Act
        final result = await movieRepositoryImpl.getMovieList();
//Assert
        verify(
          () => mockRemoteDataSource.getMovieList(),
        );
        expect(result, equals(Right(tMovieEntityList)));
      });
      test('should return failure when call is unsuccesfull', () async {
        //Arrange
        when(
          () => mockRemoteDataSource.getMovieList(),
        ).thenThrow(ServerException());
        //Act
        final result = await movieRepositoryImpl.getMovieList();
//Assert
        verify(
          () => mockRemoteDataSource.getMovieList(),
        );
        expect(result, equals(Left(ServerFailure())));
      });
    });
    group('device is offline', () {
      setUp(() {
        when(
          () => mockNetworkInfo.isConnected,
        ).thenAnswer((_) async => false);
      });
      test('should return failure', () async {
        //Arrange
        /// No arrange as datasource is not called if no network is found
        //Act
        final result = await movieRepositoryImpl.getMovieList();
//Assert
        verifyNever(
          () => mockRemoteDataSource.getMovieList(),
        );
        expect(result, equals(Left(ServerFailure())));
      });
    });
  });
}

While checking for exceptions, we should not call the function as it results in exceptions. It should be called within the expect() function. While writing tests we should try to consider every possible scenario. The verifyNever verifies that mockRemoteDataSource.getMovieList() isn’t called.

Now let’s write the implementation of the repository

Eg. Movie Repository Implementation. lib/features/movie/data/repositories/movie_repository_impl.dart

import 'package:dartz/dartz.dart';

import '../../../../core/error/exceptions.dart';
import '../../../../core/error/failure.dart';
import '../../../../core/network/network_info.dart';
import '../../domain/entities/movie_entity.dart';
import '../../domain/repositories/movie_repository.dart';
import '../datasources/video_list_remote_datasource.dart';

class MovieRepositoryImpl implements MovieRepository {
  final NetworkInfo networkInfo;
  final MovieListRemoteDataSource movieListRemoteDataSource;
  MovieRepositoryImpl({
    required this.networkInfo,
    required this.movieListRemoteDataSource,
  });
  [@override](http://twitter.com/override)
  Future<Either<Failure, List<MovieEntity>>> getMovieList() async {
    if (await networkInfo.isConnected) {
      try {
        final movieList = await movieListRemoteDataSource.getMovieList();
        return Right(movieList);
      } on ServerException {
        return Left(ServerFailure());
      }
    } else {
      return Left(ServerFailure());
    }
  }
}

After this, the test should pass and the data layer has been completed.

Finally, we have the following file and folder


DataLayer in lib


DataLayer in test


Fixture in test


Lib structure

In the next part, we will finish the presentation layer and dependency injection. See you there :)

Learning TDD with Clean Architecture for Flutter (Domain Layer) Part II

Safal Shrestha — Thu, 11 Aug 2022 16:49:00 +0000

Part I here
Part III here
Part IV here

Welcome back to the Part II of this series. Let’s continue from where we left. Here we will begin to code and finish TDD for the domain layer.

TDD Clean Architecture

Now we know a little bit about TDD and Clean Architecture, let us combine those two to get the best of both worlds. Before jumping onwards here are a few things :

We will be writing a unit test.
We will be using Mocktail to mock the dependencies.

 class MockAwsDataSource extends Mock implements AwsDataSource {} 
    // To mock class AwsDataSourece using mocktail

While testing any class, mock all the classes/dependencies inside it except the class we are testing and control all the functions inside those classes.
You should have a similar folder structure inside the test folder i.e. mimic the lib folder structure inside the test folder.

You should have basic knowledge on dart and abstraction

Domain Layer

It is one of the most important layers. It should remain unchanged even if all other layer changes. We should always start with the domain layer.

The domain layer consists of entities, repositories, and use cases.

Entities

It is a lightweight domain object and the basic data structure that we will absolutely need.

Eg. Entity of Movie lib/features/movie/domain/entities/movie_entity.dart

 import 'package:equatable/equatable.dart';

    class MovieEntity extends Equatable {
      final String movieId;
      final String title;
      final String thumbnail;
      final String movieUrl;
      final bool unlocked;
      const MovieEntity({
        required this.movieId,
        required this.title,
        required this.thumbnail,
        required this.movieUrl,
        required this.unlocked,
      });

    @override
      List<Object> get props {
        return [
          movieId,
          title,
          thumbnail,
          movieUrl,
          unlocked,
        ];
      }
    }

Equatable overrides == and hashCode for you so you don't have to waste your time writing lots of boilerplate code.

Repositories

It is in both the domain and data layer. Its definition is in the domain layer and implementation is in the data layer allowing total independence of the domain layer.

Eg. Repository of Movie lib/features/movie/domain/repositories/movie_repository.dart

  import 'package:dartz/dartz.dart';
    import '../../../../core/error/failure.dart';
    import '../entities/movie_entity.dart';
    abstract class MovieRepository {
      Future<Either<Failure, List<MovieEntity>>> getMovieList();
    }

It will have a method to get a list of movies, i.e. list of movie entities. Future>> will ensure error handling . Let us move on. Wait a minute what is either keyword? It allows a function to return between failure and List of movie entities, not both. It has been obtained from package Dartz which gives functional programming capabilities to dart. Failure class was defined in the core/error file to define the failure of the code.

In core the features, abstraction or module that is used in other features are defined

Eg. Failure is defined in lib/core/error/failure.dart

import 'package:equatable/equatable.dart';
    abstract class Failure extends Equatable {
     @override
      List<Object?> get props => [];
    }
    //General Failures
    class ServerFailure extends Failure {}
    class CacheFailure extends Failure {}

Usecases

Use Cases are where the business logic gets executed. It calls a repository to get data.

Eg. Usecase to get movie list lib/features/movie/domain/usecases/get_movie_list_usecase.dart

    import 'package:dartz/dartz.dart';
    import '../../../../core/error/failure.dart';
    import '../../../../core/usecases/usecase.dart';
    import '../entities/movie_entity.dart';
    import '../repositories/movie_repository.dart';

    class GetMovieListUsecase implements UseCase<List<MovieEntity>, NoParams> {
      final MovieRepository movieRepository;
      GetMovieListUsecase({
        required this.movieRepository,
      });

    @override
      Future<Either<Failure, List<MovieEntity>>> call(NoParams params) async {
        return await movieRepository.getMovieList();
      }
    }

GetVideoLiseUsecase implements use-case inside lib/core/use-case . We are defining rules for use cases there.

Eg. Base use-case is defined in lib/core/usecases/usecase.dart

 import 'package:dartz/dartz.dart';
    import 'package:equatable/equatable.dart';
    import '../error/failure.dart';
    abstract class UseCase<Type, Params> {
      Future<Either<Failure, Type>> call(Params params);
    }

    class NoParams extends Equatable {
      @override
      List<Object?> get props => [];
    }

Wait a minute this was supposed to be TDD Clean Architecture. Shouldn’t we write a test first?

Yes, before writing a use case, we should first write the test first. Just imagine the above code hasn’t been written yet for now and let’s write a test.

Test file should end with ‘_test.dart’ and you can run test by typing flutter test in terminal or you can run them manually clicking run. While naming the test give it the same name as the file you are trying to test and add ‘ _test ’ to it

Eg. Test for use-case test/features/movie/domain/usecases/get_movie_list_usecase_test.dart

 import 'package:dartz/dartz.dart';
 import 'package:flutter_test/flutter_test.dart';
 import 'package:mocktail/mocktail.dart';

class MockMovieRepository extends Mock implements MovieRepository {}
  void main() {
      late GetMovieListUsecase getMovieListUsecase;
      late MockMovieRepository mockMovieRepository;
      final tMovieList = [
        const MovieEntity(
          movieId: 'movieId',title: 'title',thumbnail: 'thumbnail',
      movieUrl: 'movieUrl',unlocked: true,
        ),
        const MovieEntity(
          movieId: 'movieIds',title: 'titles',thumbnail: 'thumbnails',
      movieUrl: 'movieUrls',unlocked: false,
        )   
      ];
      setUp(() {
        mockMovieRepository = MockMovieRepository();
        getMovieListUsecase =
            GetMovieListUsecase(movieRepository: mockMovieRepository);
      });
      test(
        'should get list of movie',
        () async {
          // arrange
          when(() => mockMovieRepository.getMovieList())
              .thenAnswer((_) async => Right(tMovieList));

    // act
          final result = await getMovieListUsecase(NoParams());

    // assert
          verify(() => mockMovieRepository.getMovieList());

    expect(result, Right(tMovieList));
          verifyNoMoreInteractions(mockMovieRepository);
        },
      );
    }

Now let’s explain the code

We are testing GetMovieListUsecase in get_movie_list_usecase.dart which implements a base use case in lib/core/usecases/usecase.dart . GetMovieListUsecase use case calls a repository for data, so the repository must be mocked to test the use case. After mocking the repository, we write the test.

Now just like in the original dart file, there is the main file that will be executed. The main function contains the test.

First, we define all the dependencies we need.

Then we instantiate them in setUp. If we look at the test there are three parts.

In arrange we control the outcome of the functions.

In act, we run the functions.

In assert, we verify/check if the test is successful or not. verify function is making sure that the function has been executed. expect to compare the result and verifyNoMoreInteractions to ensure that the repository is no longer being used or interacted with.

If we look closely, we can see that the test looks like documentation explaining to us what the code is supposed to do.

You might be wondering if usecase hasn’t been created yet how do we map or visualize the test. Here comes, abstraction to the rescue . Even though getMovieListUsecase hasn’t been created , the usecase has been defined using abstract class. We can use this abstract class to visualize what the usecase class will be like and use it to write the test(most of the time). So interface/abstract class are very important in TDD. After writing the test, we write the usecase until the test in successful and refactor it as needed.

Only use-case needs to be tested in the domain layer as the repository and entity have nothing to test as they are very simple.

Finally, we have the following file and folder


Domain Layer in lib


Domain Layer in test

In my next post, we will implement TDD for the Data layer.

Learning TDD with Clean Architecture for Flutter Part I

Safal Shrestha — Mon, 08 Aug 2022 10:49:00 +0000

This will be four-part series in which we will learn about TDD in Flutter.
Part II here
Part III here
Part IV here

TDD(Test Driven Development)

TDD is an approach in which the test is written to validate the code that we write. Here the test is written and the code is modified to pass the test. It is also known as Test First Development.

TDD cycle defines

Write a test
Make it run
Change the code to make it right i.e. Refactor
Repeat process

TDD Advantages

Documentation
Fewer bugs
Adding new functionalities becomes easier
Faster in the long run
Tidier Code
Forces you to focus on one thing
Clean Interfaces

TDD Disadvantages

Slow Process
Faulty test code/No Silver Bullet
All members should do it
Increases Complexity
Design dependent

Clean Architecture

Clean Architecture is also known as Domain-Driven Design. The primary idea in Clean Architecture is to make the solution adaptive, and keep the core business or application logic use cases independent of frontend and external frameworks.

It produces the system that is:

Independent of Frameworks
Testable
Independent of UI
Independent of Database
Independent of any external agency

In clean architecture, codes are divided into layers. Inner layers are independent of the outer layer and changes can be made to the outer layer without ever touching the inner layer. It follows the **Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. Here it contains four layers:

Entities

Entities encapsulate Enterprise-wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise.

Use Cases

The software in this layer contains application-specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities and direct those entities to use their enterprise-wide business rules to achieve the goals of the use case.

Interface Adapters

The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities to the format most convenient for some external agency such as the Database or the Web.

Frameworks and Drivers

The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally, you don’t write much code in this layer other than glue code that communicates to the next circle inwards.

There can be more than four layers. This diagram is only symbolic. There can be more layer as long as it follows dependency rule.

Clean Architecture and Flutter

To make things clear and Flutter-specific, we are using Reso Coder’s Flutter Clean Architecture Proposal. It consists of three layers :

Domain Layer

It is the inner layer that shouldn’t be susceptible to the whims of changing data sources or porting our app to Angular Dart. It will contain only the core business logic (use cases) and business objects (entities). It should be totally independent of every other layer.

Data Layer

The data layer consists of a Repository implementation (the contract comes from the domain layer) and data sources — one is usually for getting remote (API) data and the other for caching that data. A repository is where you decide if you return fresh or cached data when to cache it and so on.

Presentation Layer

This layer contains UI and state management approaches.

Folder Structure

In this post, you learn a little bit about test-driven development and clean architecture. For more, head on to part II.