File utilities and wrappers that may be useful for some projects.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

93 lines
4.7KB

  1. # File utilities unit test configuration.
  2. #
  3. # This configuration is not likely to be used for all unit tests, but you should
  4. # read the appropriate sections carefully. Unit test failures will be reported
  5. # when a) this file is missing and b) this file is not configured for your test
  6. # environment.
  7. #
  8. # WE WILL NOT ACCEPT BUG REPORTS FOR FAILING UNIT TESTS CAUSED BY INDIVIDUALS
  9. # WHO DID NOT READ THE DOCUMENTATION FOR TESTING CONFIGURATION(S).
  10. app:
  11. # FindConfig tests.
  12. #
  13. # Read the following section carefully along with each subsection if you're
  14. # running tests. Failure to change values to locations appropriate for your
  15. # test environment will cause FindConfig tests to fail.
  16. #
  17. # WE WILL NOT ACCEPT BUG REPORTS FOR FAILING UNIT TESTS CAUSED BY INDIVIDUALS
  18. # WHO DID NOT READ THIS SECTION.
  19. #
  20. # Pay particular attention to each location specified in the config herewith.
  21. # Specifically, note that the *entire* path is used. This means that paths are
  22. # interpolated via filepath.Abs() to obtain the absolute path, then the
  23. # containing directory and the file name are split out into their own parts.
  24. # What we do with each component depends on the test itself. For tests that
  25. # require an environment variable to be set, we'll set it to the contents of
  26. # the interpolated directory. For tests that include a -base suffice, we pass
  27. # the contents of -base into FindConfig's argument of the same name.
  28. find-config:
  29. # Absolute path test. This should bail before any other file location tests
  30. # are attempted.
  31. abs: "/full/path/to/file/change.me"
  32. # We use the sample YAML application configuration that comes with our app.
  33. cwd: ./config.sample.yaml
  34. # Here we use the same value as above since we cannot guarantee similar
  35. # files across environments (one option is ~/.config/fontconfig, but that's
  36. # only likely to exist if you have an X server installed). The unit tests
  37. # work by taking the absolute path of this location, splitting out the root,
  38. # stting it to the XDG_CONFIG_HOME environment variable, and then running
  39. # the config finder.
  40. xdg-config-home: ./app/util_test.go
  41. # For XDG_CONFIG_DIRS, we need to be somewhat more creative. As a
  42. # consequence, we're now entering terrain that is unlikely to be true across
  43. # all systems. For this reason, you may need to change the sammple value
  44. # (below) for ~/.config/fontconfig to somewhere else.
  45. xdg-config-dirs:
  46. - ./config.sample.yaml
  47. - ~/.config/fontconfig
  48. # This configuration controls the manually-tested ~/.config code path which
  49. # is usually reached when both XDG_CONFIG_HOME and XDG_CONFIG_DIRS are
  50. # unset. As with xdg-config-dirs (above), the same caveat applies. If
  51. # ~/.config/fontconfig doesn't exist, you'll need to create it. However,
  52. # bear in mind that for this particular test, FindConfig actually uses the
  53. # hard-cooded path ~/.config. If you genuinely wish to test this, ensure the
  54. # directory ~/.config has been created and populate it with a file for which
  55. # you wish to test its presence below.
  56. xdg-config-home-forced: ~/.config/fontconfig
  57. # Controls the argument for `base` in FindConfig. If this is the empty
  58. # string, no paths are appended before examining the directory for the
  59. # basename of the file specified in xdg-config-home-forced.
  60. #
  61. # For example, if your application typically looks under ~/.config/app for
  62. # its configuration file `config.json`, to emulate this, you would set the
  63. # value of xdg-config-home-forced to ~/.config/app/config.json and then set
  64. # this value to "app". This is because the value of `base` in FindConfig is
  65. # always appended to the root "${HOME}/.config", which is hard coded.
  66. xdg-config-home-base: ""
  67. # For the /etc test, we pick a file that's fairly common across most Linux
  68. # distributions. A better option for more widely supported UNIX and
  69. # UNIX-like systems might be to test for /etc/resolv.conf. Either way, the
  70. # same requirements apply here as with the prior tests: The file should
  71. # exist, and it should exist in the hard-coded path /etc.
  72. etc: /etc/os-release
  73. # As with xdg-config-home-base, this controls the value of `base` passed
  74. # into FindConfig. If this is anything but the empty string, it is appended
  75. # to /etc. For example, if you were emulating a configuration file for your
  76. # application, the value of etc (above) should read
  77. # "/etc/appname/config.json" and the value of this should be set to
  78. # "appname". This is because FindConfig simply looks in /etc for the
  79. # specified file, but the "base" directory under /etc can be specific
  80. # separately (and in fact the server and client both pass in "appname" for
  81. # the value of `base`).
  82. etc-base: ""