|
| 1 | +# This is a template for adding tests to the flutter/tests registry. |
| 2 | +# |
| 3 | +# To submit a new batch of tests, copy this file to create a new file |
| 4 | +# in this directory, update it as described below, and submit it as a |
| 5 | +# new PR to this repository. |
| 6 | +# |
| 7 | +# New files should be named `foo.test` where `foo` is a description of |
| 8 | +# the project whose tests are being added. (The file named |
| 9 | +# `template.test` is skipped automatically.) |
| 10 | +# |
| 11 | +# Lines beginning with a "#" are ignored. Delete all such lines from |
| 12 | +# this template before submitting a new `.test` file (you may add new |
| 13 | +# comments if you have something to say that doesn't fit in one of the |
| 14 | +# meaningful lines). Also delete blank lines like the following: |
| 15 | + |
| 16 | +# The contact lines must contain the e-mail addresses, one to a line, |
| 17 | +# of one or more people who will be able to help if a problem is found |
| 18 | +# with a test. People on this list should be able to respond to |
| 19 | +# e-mails within about 72 hours. If there is a problem with a test and |
| 20 | +# we cannot reach any of the people listed, then we will probably |
| 21 | +# remove the tests. |
| 22 | +contact=foo@example.com |
| 23 | +contact=bar@example.com |
| 24 | + |
| 25 | +# The fetch line(s) must contain one or more commands that fetch the |
| 26 | +# tests into a new directory called "tests" in the current directory. |
| 27 | +# The example below clones the dnfield/flutter_svg GitHub repository |
| 28 | +# then checks out a specific revision. |
| 29 | +# |
| 30 | +# Our current policy is that all tests should be in public GitHub |
| 31 | +# repositories. (This way, we don't take on additional dependencies on |
| 32 | +# other services that may or not go down. We already depend on GitHub, |
| 33 | +# so if GitHub goes down it doesn't matter that we can't reach |
| 34 | +# contributed tests.) If you have some tests to contribute that are |
| 35 | +# not and will not be in GitHub, please contact ian@hixie.ch before |
| 36 | +# submitting a PR proposing to add such tests. We may make exceptions |
| 37 | +# if your tests are especially valuable. |
| 38 | +# |
| 39 | +# The checkout must always check out the exact same set of tests. Do |
| 40 | +# not check out the current master branch or some such; always fetch a |
| 41 | +# specific revision. You may regularly submit PRs that update the |
| 42 | +# revision being used. |
| 43 | +# |
| 44 | +# Each fetch directive is processed as follows: the value is split on |
| 45 | +# spaces (without honoring quotes or backslash escapes or anything |
| 46 | +# like that), then the first segment is used as the executable to ask |
| 47 | +# the operating system to run, and the rest are treated as arguments |
| 48 | +# to pass to that process. |
| 49 | +# |
| 50 | +# The commands specified on the "fetch" lines must return the exit |
| 51 | +# code 0 or else the tests will be skipped entirely. The "git" program |
| 52 | +# will be on the path. |
| 53 | +# |
| 54 | +# There must be at least one "fetch" line. (In fact currently there |
| 55 | +# must be at least two, and the first two must follow the pattern |
| 56 | +# below more or less exactly. Additional lines are allowed e.g. to |
| 57 | +# initialize and update submodules, but this should be rare. If this |
| 58 | +# is a problem, let us know in your PR.) |
| 59 | +fetch=git clone https://github.com/USERNAME/REPOSITORY.git tests |
| 60 | +fetch=git -C tests checkout 0123456789abcdef0123456789abcdef01234567 |
| 61 | + |
| 62 | +# The "update" lines specify paths (relative to the newly created |
| 63 | +# "tests" directory) in which to run a flutter command to |
| 64 | +# automatically update the code to fix breaking changes. The command |
| 65 | +# will be run in turn in each specified directory. The root can be |
| 66 | +# specified by using the path "." as that represents the "current" |
| 67 | +# directory. Multiple paths may be specified by specifying multiple |
| 68 | +# "update" lines. |
| 69 | +# |
| 70 | +# The command that updates the code may fail, in which case the tests |
| 71 | +# are considered to have failed. This helps catch cases where |
| 72 | +# automatically updating the code doesn't work. |
| 73 | +# |
| 74 | +# There must be at least one "update" line. |
| 75 | +update=. |
| 76 | + |
| 77 | +# The test lines specify commands to run to execute the actual tests. |
| 78 | +# Each of these should return either 0 to indicate success, or a |
| 79 | +# non-zero exit code to report failure. |
| 80 | +# |
| 81 | +# The "flutter" tool and the "dart" program will be in the path. |
| 82 | +# |
| 83 | +# If there are multiple directories, create a shell script in the |
| 84 | +# repository to enter each directory and run the tests in that |
| 85 | +# directory, returning non-zero as soon as any set of tests fails. You |
| 86 | +# can have multiple such scripts. In the example below, we run |
| 87 | +# "flutter test" in the root of the repository, a "more_tests.sh" |
| 88 | +# shell script from that same directory (the "./" indicates it isn't a |
| 89 | +# command to search for on the path), and the "extra_tests.dart" |
| 90 | +# program in the "dev" directory, run via "dart". |
| 91 | +test=flutter test |
| 92 | +test=./more_tests.sh |
| 93 | +test=dart dev/extra_tests.dart |
| 94 | + |
| 95 | +# To test your tests, check out the flutter/flutter repository and |
| 96 | +# then, from the root of that repository, run: |
| 97 | +# bin/flutter; time bin/cache/dart-sdk/bin/dart dev/customer_testing/run_tests.dart --repeat=100 <path> |
| 98 | +# ...where <path> is the path to this file. This should run with no |
| 99 | +# output, without failing, and should in total take less than 15 |
| 100 | +# minutes (a hundred runs of your tests taking just a few seconds |
| 101 | +# each). If your tests take longer, mention this in your PR and we |
| 102 | +# will evaluate them to see how valuable they are (e.g. how unique and |
| 103 | +# different they are compared to other tests we already have). The |
| 104 | +# more valuable the tests, the more likely we are to accept them |
| 105 | +# despite them taking a long time to run. |
| 106 | + |
| 107 | +# See also the `README.md` file in the root of this repository. |
0 commit comments