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.

RUNNING_TESTS 4.2KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109
  1. Installing gems for testing
  2. ===========================
  3. Remove your .bundle/config if you've already installed Redmine without
  4. the test dependencies. Then, run `bundle install`.
  5. Running Tests
  6. =============
  7. Run `rake --tasks test` to see available tests.
  8. Run `rake test` to run the entire test suite (except the tests for the
  9. Apache perl module Redmine.pm and Capybara tests, see below).
  10. You can run `ruby test/unit/issue_test.rb` for running a single test case and
  11. `ruby test/unit/issue_test.rb -n test_create` for running a single test.
  12. You can run tests in parallel by setting the PARALLEL_WORKERS environment
  13. variable:
  14. `PARALLEL_WORKERS=8 rake test`
  15. Before running tests, you need to configure both development
  16. and test databases.
  17. Creating test repositories
  18. ==========================
  19. Redmine supports a wide array of different version control systems.
  20. To test the support, a test repository needs to be created for each of those.
  21. Run `rake --tasks test:scm:setup` for a list of available test-repositories or
  22. run `rake test:scm:setup:all` to set up all of them. The repositories are
  23. unpacked into {redmine_root}/tmp/test.
  24. If the test repositories are not present, the tests that need them will be
  25. skipped.
  26. Creating a test LDAP database
  27. =============================
  28. Redmine supports using LDAP for user authentications. To test LDAP
  29. with Redmine, load the LDAP export from test/fixtures/ldap/test-ldap.ldif
  30. into a testing LDAP server. Make sure that the LDAP server can be accessed
  31. at 127.0.0.1 on port 389.
  32. If your LDAP server is not running on localhost, you can use the
  33. REDMINE_TEST_LDAP_SERVER environment variable to specify another host.
  34. Setting up the test LDAP server is beyond the scope of this documentation.
  35. The OpenLDAP project provides a simple LDAP implementation that should work
  36. good as a test server.
  37. If the LDAP is not available, the tests that need it will be skipped.
  38. Running Redmine.pm tests
  39. ========================
  40. (work in progress)
  41. Running the tests for the Redmine.pm perl module needs a bit more setup.
  42. You need an Apache server with mod_perl, mod_dav_svn and Redmine.pm configured.
  43. See: http://www.redmine.org/projects/redmine/wiki/Repositories_access_control_with_apache_mod_dav_svn_and_mod_perl
  44. You need an empty repository accessible at http://127.0.0.1/svn/ecookbook
  45. Then, you can run the tests with:
  46. `ruby test\extra\redmine_pm\repository_subversion_test.rb`
  47. If your svn server is not running on localhost, you can use the
  48. REDMINE_TEST_DAV_SERVER environment variable to specify another host.
  49. Running Capybara tests
  50. ======================
  51. You need to have Chrome installed and available in your PATH.
  52. Chromedriver is managed by the `webdrivers` gem (https://rubygems.org/gems/webdrivers)
  53. Capybara tests can be run with:
  54. `rails test:system`
  55. The following environment variables can be used to configure your system tests setup:
  56. `CAPYBARA_SERVER_HOST`: configure server to run on a custom IP which can be, for example, your remote Selenium IP or 0.0.0.0 to listen an all connections
  57. `CAPYBARA_SERVER_PORT`: configure server port
  58. `SELENIUM_REMOTE_URL`: remote Selenium URL
  59. `CAPYBARA_APP_HOST`: by default, the tests expect to have the application running on your localhost. Using this variable, you can set a custom URL
  60. `GOOGLE_CHROME_OPTS_ARGS`: configure Google Chrome Options arguments as a comma-delimited string. For example, it can be used to run the tests in headless mode:
  61. `export GOOGLE_CHROME_OPTS_ARGS="headless,disable-gpu,no-sandbox,disable-dev-shm-usage"`
  62. One use case of these variables is to run the system tests on a remote Selenium/ChromeDriver (eg: Docker).
  63. Running RuboCop, a static code analyzer
  64. =======================================
  65. RuboCop allows you to find out if the code violates the Ruby Style Guide.
  66. Checking with RuboCop is recommended when you write patches.
  67. You can run RuboCop with:
  68. `bundle exec rubocop [file ...]`
  69. Running Stylelint, a static code analyzer for CSS files
  70. =======================================
  71. You need to have NodeJS and Yarn installed and available in your PATH:
  72. https://nodejs.org/en/download/package-manager/
  73. https://legacy.yarnpkg.com/lang/en/docs/install/#mac-stable
  74. Install Stylelint:
  75. `yarn install`
  76. You can run Stylelint with:
  77. `node_modules/.bin/stylelint "public/stylesheets/**/*.css"`