# This is a template for adding tests to the flutter/tests registry.

#

# To submit a new batch of tests, copy this file to create a new file

# in this directory, update it as described below, and submit it as a

# new PR to this repository.

#

# New files should be named `foo.test` where `foo` is a description of

# the project whose tests are being added. (The file named

# `template.test` is skipped automatically.)

#

# Lines beginning with a "#" are ignored. Delete all such lines from

# this template before submitting a new `.test` file (you may add new

# comments if you have something to say that doesn't fit in one of the

# meaningful lines). Also delete blank lines like the following:

# The contact lines must contain the e-mail addresses, one to a line,

# of one or more people who will be able to help if a problem is found

# with a test. People on this list should be able to respond to

# e-mails within about 72 hours. If there is a problem with a test and

# we cannot reach any of the people listed, then we will probably

# remove the tests.

contact=foo@example.com

contact=bar@example.com

# The fetch line(s) must contain one or more commands that fetch the

# tests into a new directory called "tests" in the current directory.

# The example below clones the USERNAME/REPOSITORY GitHub repository

# then checks out a specific revision.

#

# Our current policy is that all tests should be in public GitHub

# repositories. (This way, we don't take on additional dependencies on

# other services that may or not go down. We already depend on GitHub,

# so if GitHub goes down it doesn't matter that we can't reach

# contributed tests.) If you have some tests to contribute that are

# not and will not be in GitHub, please contact ian@hixie.ch before

# submitting a PR proposing to add such tests. We may make exceptions

# if your tests are especially valuable.

#

# The checkout must always check out the exact same set of tests. Do

# not check out the current main branch or some such; always fetch a

# specific revision. You may regularly submit PRs that update the

# revision being used.

#

# Each fetch directive is processed as follows: the value is split on

# spaces (without honoring quotes or backslash escapes or anything

# like that), then the first segment is used as the executable to ask

# the operating system to run, and the rest are treated as arguments

# to pass to that process.

#

# The command must be able to run identically on Windows, macOS, and

# Linux. If you just stick with simple git commands you should be

# fine.

#

# The commands specified on the "fetch" lines must return the exit

# code 0 or else the tests will be skipped entirely. The "git" program

# will be on the path.

#

# There must be at least one "fetch" line. (In fact currently there

# must be at least two, and the first two must follow the pattern

# below more or less exactly. Additional lines are allowed e.g. to

# initialize and update submodules, but this should be rare. If this

# is a problem, let us know in your PR.)

fetch=git clone https://github.com/USERNAME/REPOSITORY.git tests

fetch=git -C tests checkout 0123456789abcdef0123456789abcdef01234567

# The "setup" lines specify commands to run before the "update" or

# "test" lines are handled. This is useful for things like generating

# mocks before running the "update" and "test" steps.

#

# Commands specified using "setup=" must work identically on Windows,

# macOS, and Linux. This generally means you want to limit yourself to

# simple commands. For anything more elaborate, consider creating a

# "setup.sh" shell script to run on macOS and Linux and a "setup.bat"

# batch file to run on Windows (referencing it without the extension

# here should mean that in runs the shell script on Unix systems and

# the batch file on Windows, because of how Windows looks up commands).

# On Windows, these commands are executed via

# `CMD.EXE /S /C "command..."`.

#

# Alternatively, you can use a platform-specific setup line:

# setup.windows= to run a command on Windows only.

# setup.macos= to run a command on MacOS only.

# setup.linux= to run a command on Linux only.

# setup.posix= to run a command on MacOS and Linux only.

setup.posix=setup.sh

setup.windows=setup.bat

# The "update" lines specify paths (relative to the newly created

# "tests" directory) in which to run a flutter command to

# automatically update the code to fix breaking changes. The command

# will be run in turn in each specified directory. The root can be

# specified by using the path "." as that represents the "current"

# directory. Multiple paths may be specified by specifying multiple

# "update" lines.

#

# Each specified directory must contain a "pubspec.yaml" file.

#

# The path must be specified using forward slashes for path

# separators, as on Unix systems. The path is automatically converted

# for use on Windows.

#

# The command that updates the code may fail, in which case the tests

# are considered to have failed. This helps catch cases where

# automatically updating the code doesn't work.

#

# The actual commands run in each directory given here are:

# flutter packages get

# dart fix --apply

#

# There must be at least one "update" line.

update=.

# The test lines specify commands to run to execute the actual tests.

# Each of these should return either 0 to indicate success, or a

# non-zero exit code to report failure.

#

# The "flutter" tool and the "dart" program will be in the path.

#

# If there are multiple directories, create a shell script in the

# repository to enter each directory and run the tests in that

# directory, returning non-zero as soon as any set of tests fails. You

# can have multiple such scripts. In the example below, we run

# "flutter test" in the root of the repository, a "more_tests"

# shell script from that same directory, and the "extra_tests.dart"

# program in the "dev" directory, run via "dart".

#

# Commands specified using "test=" must work identically on Windows,

# macOS, and Linux. This generally means you want to limit yourself to

# simple commands like `flutter test`. For anything more elaborate,

# consider creating a "tests" shell script to run on macOS and Linux

# and a "tests.bat" batch file to run on Windows (referencing it

# without the extension here should mean that in runs the shell script

# on Unix systems and the batch file on Windows, because of how

# Windows looks up commands). On Windows, these commands are executed

# via `CMD.EXE /S /C "command..."`.

#

# Alternatively, you can use a platform-specific test line:

# test.windows= to run a command on Windows only.

# test.macos= to run a command on MacOS only.

# test.linux= to run a command on Linux only.

# test.posix= to run a command on MacOS and Linux only.

#

# There must be sufficient test lines specified such that tests are

# available on each of Windows, MacOS, and Linux. In the example

# below, we run mytest.bat on Windows and mytest.sh on MacOS and Linux

# (in both cases, from the "scripts" directory).

#

# You are encouraged to also use "flutter analyze" to catch problems

# that affect code that isn't tested, but if you do, please use the

# "--no-fatal-infos" argument so that we can continue to change lints

# without having to e.g. reformat all your code any time we fix a

# minor bug in some esoteric stylistic lint. :-)

#

# If your tests need a setup step first, include it as a test step.

# Making such a setup step idempotent (and fast) will help keep the

# total time reasonable (see below). Avoid setup steps that require

# downloading extra resources from sites other than pub and GitHub,

# as that will increase the flakiness potential of your tests (and

# we will remove flaky tests).

test=flutter analyze --no-fatal-infos

test=flutter test

test=more_tests

test=dart dev/extra_tests.dart

test.windows=scripts\mytest.bat

test.posix=scripts/mytest.sh

# To test your tests, run:

#

# scripts/verify_tests_on_main.sh --local-flutter --repeat 100 registry/NAME.test

#

# ...where registry/NAME.test is this file.

#

# This should run with no output, without failing, and should in total

# take less than 15 minutes (a hundred runs of your tests taking just

# a few seconds each). If your tests take longer, mention this in your

# PR and we will evaluate them to see how valuable they are (e.g. how

# unique and different they are compared to other tests we already

# have). The more valuable the tests, the more likely we are to accept

# them despite them taking a long time to run.

# See also the `README.md` file in the root of this repository.