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

• Заметка на Хабре
• https://youtu.be/rViOUxsGs2k
• https://youtu.be/FndheiFSvPY
• https://youtu.be/zIdsacU_y-k
• Альтернатива

Inspired by flutter_bloc example.

$ 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 = '[email protected]';
// 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'

# execute command line
$ flutter test

• Use flutter devices to get target device id

$ flutter devices

• Config targetDeviceId in main_test.dart

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

• Execute command line with target devices

$ flutter drive

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:

• "Introducing BDD", by Dan North (2006)
• Wikipedia
• "The beginner's guide to BDD (behaviour-driven development)", By Konstantin Kudryashov, Alistair Stead, Dan North
• Behaviour-Driven Development

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.

• E-Mail: [email protected]
• Telegram: @AndrewKachanov

• Patreon
• QIWI

😺 We love cats!