Home

Awesome

flutter_idiomatic

It is starter kit with idiomatic code structure :) Firebase Authentication & GraphQL CRUD via BLoC. With Unit tests, Widget tests and Integration tests as BDD.

Inspired by flutter_bloc example.

How to Start

$ flutter packages pub run build_runner build --delete-conflicting-outputs

Add lib/local.dart:

const kGitHubPersonalAccessToken = 'token';
// from https://github.com/settings/tokens

const kDatabaseToken = 'token';
// from https://hasura.io/learn/graphql/graphiql?tutorial=react-native

const kDatabaseUserId = 'your@email.com';
// from https://hasura.io/learn/graphql/graphiql?tutorial=react-native

for VSCode Apollo GraphQL

$ npm install -g apollo

create ./apollo.config.js

module.exports = {
  client: {
    includes: ['./lib/**/*.dart'],
    service: {
      name: '<project name>',
      url: '<graphql endpoint>',
      // optional headers
      headers: {
        'x-hasura-admin-secret': '<secret>',
        'x-hasura-role': 'user',
      },
      // optional disable SSL validation check
      skipSSLValidation: true,
      // alternative way
      // localSchemaFile: './schema.json',
    },
  },
}

how to download schema.json for localSchemaFile

$ apollo schema:download --endpoint <graphql endpoint> --header 'X-Hasura-Admin-Secret: <secret>' --header 'X-Hasura-Role: user'

Execution Test for flutter_test

# execute command line
$ flutter test

Execution Test for flutter_driver

Execute target to iOS / Android:

$ flutter devices

Ex: (Android), default empty string
..targetDeviceId = "emulator-5554"

$ flutter drive

Why BDD (Behavior Driven Development)?

Swing Project

Flutter uses different types of tests (unit, widget, integration). You should have all types of tests in your app, most of your tests should be unit tests, less widget and a few integration tests. The test pyramid explains the principle well (using different words for the test-types).

I want to help you to start with integration tests but go a step further than the description in the flutter documentation and use the Gherkin language to describe the expected behavior. The basic idea behind Gherkin/Cucumber is to have a semi-structured language to be able to define the expected behaviour and requirements in a way that all stakeholders of the project (customer, management, developer, QA, etc.) understand them. Using Gherkin helps to reduce misunderstandings, wasted resources and conflicts by improving the communication. Additionally, you get a documentation of your project and finally you can use the Gherkin files to run automated tests.

If you write the Gherkin files, before you write the code, you have reached the final level, as this is called BDD (Behaviour Driven Development)!

Here are some readings about BDD and Gherkin:

The feature files

The first line is just a title of the feature, the other three lines should answer the questions Who, wants to achieve what and why with this particular feature. If you cannot answer those questions for a particular feature of your app then you actually should not implement that feature, there is no use-case for it.

Contacts

Support Me

😺 We love cats!