github.com/golang/dep@v0.5.4/cmd/dep/testdata/harness_tests/README.md (about)

     1  # golang/dep Integration Tests
     2  
     3  The `dep` integration tests use a consistent directory structure under `testdata`
     4  to set up the initial project state, run `dep` commands, then check against an
     5  expected final state to see if the test passes.
     6  
     7  The directory structure is as follows:
     8  
     9      testdata/
    10          harness_tests/
    11              category1/
    12                  subcategory1/
    13                      case1/
    14                          testcase.json
    15                          stdout.txt
    16                          initial/
    17                              file1.go
    18                              Gopkg.toml
    19                              ...
    20                          final/
    21                              Gopkg.toml
    22                              Gopkg.lock
    23                      case2/
    24                      ...
    25  
    26  The test code itself simply walks down the directory tree, looking for
    27  `testcase.json` files.  These files can be as many levels down the tree as
    28  desired.  The test name will consist of the directory path from `testdata` to
    29  the test case directory itself.  In the above example, the test name would be
    30  `category1/subcategory1/case1`, and could be singled out with the `-run` option
    31  of `go test` (i.e.
    32  `go test github.com/golang/dep/cmd/dep -run Integration/category1/subcategory1/case1`).
    33  New tests can be added simply by adding a new directory with the json file to
    34  the `testdata` tree.  There is no need for code modification - the new test
    35  will be included automatically.
    36  
    37  The json file needs to be accompanied by `initial` and `final` directories. The
    38  `initial` is copied verbatim into the test project before the `dep` commands are
    39  run, and the `manifest` and `lock` files in `final`, if present, are used to
    40  compare against the test project results after the commands. The `stdout.txt` file
    41  is optional, and if present will be compared with command output.
    42  
    43  The `testcase.json` file has the following format:
    44  
    45      {
    46        "commands": [
    47          ["init"],
    48          ["ensure", "github.com/sdboyer/deptesttres"]
    49        ],
    50        "gopath-initial": {
    51          "github.com/sdboyer/deptest": "v0.8.0",
    52          "github.com/sdboyer/deptestdos": "a0196baa11ea047dd65037287451d36b861b00ea"
    53        },
    54        "vendor-initial": {
    55          "github.com/sdboyer/deptesttres": "v2.1.0",
    56          "github.com/sdboyer/deptestquatro": "cf596baa11ea047ddf8797287451d36b861bab45"
    57        },
    58        "vendor-final": [
    59          "github.com/sdboyer/deptest",
    60          "github.com/sdboyer/deptestdos",
    61          "github.com/sdboyer/deptesttres",
    62          "github.com/sdboyer/deptestquatro"
    63        ],
    64        "error-expected": "something went wrong"
    65      }
    66  
    67  All of the categories are optional - if the `imports` list for a test is empty,
    68  for example, it can be completely left out.
    69  
    70  The test procedure is as follows:
    71  
    72  1. Create a unique temporary directory (TMPDIR) as the test run's `GOPATH`
    73  2. Create `$TMPDIR/src/github.com/golang/notexist` as the current project
    74  3. Copy the contents of `initial` input directory to the project
    75  4. Fetch the repos and versions in `gopath-initial` into `$TMPDIR/src` directory
    76  5. Fetch the repos and versions in `vendor-initial` to the project's `vendor` directory
    77  6. Run `commands` on the project, in declaration order
    78  7. Ensure that, if any errors are raised, it is only by the final command and their string output matches `error-expected`
    79  8. Ensure that, if a stdout.txt file is present, the command's output matches (excluding trailing whitespace).
    80  9. Check the resulting files against those in the `final` input directory
    81  10. Check the `vendor` directory for the projects listed under `vendor-final`
    82  11. Check that there were no changes to `src` listings
    83  12. Clean up
    84  
    85  Note that for the remote fetches, only git repos are currently supported.