123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109 |
- Installing gems for testing
- ===========================
-
- Remove your .bundle/config if you've already installed Redmine without
- the test dependencies. Then, run `bundle install`.
-
- Running Tests
- =============
-
- Run `rake --tasks test` to see available tests.
- Run `rake test` to run the entire test suite (except the tests for the
- Apache perl module Redmine.pm and Capybara tests, see below).
-
- You can run `ruby test/unit/issue_test.rb` for running a single test case and
- `ruby test/unit/issue_test.rb -n test_create` for running a single test.
-
- You can run tests in parallel by setting the PARALLEL_WORKERS environment
- variable:
- `PARALLEL_WORKERS=8 rake test`
-
- Before running tests, you need to configure both development
- and test databases.
-
- Creating test repositories
- ==========================
-
- Redmine supports a wide array of different version control systems.
- To test the support, a test repository needs to be created for each of those.
-
- Run `rake --tasks test:scm:setup` for a list of available test-repositories or
- run `rake test:scm:setup:all` to set up all of them. The repositories are
- unpacked into {redmine_root}/tmp/test.
-
- If the test repositories are not present, the tests that need them will be
- skipped.
-
- Creating a test LDAP database
- =============================
-
- Redmine supports using LDAP for user authentications. To test LDAP
- with Redmine, load the LDAP export from test/fixtures/ldap/test-ldap.ldif
- into a testing LDAP server. Make sure that the LDAP server can be accessed
- at 127.0.0.1 on port 389.
-
- If your LDAP server is not running on localhost, you can use the
- REDMINE_TEST_LDAP_SERVER environment variable to specify another host.
-
- Setting up the test LDAP server is beyond the scope of this documentation.
- The OpenLDAP project provides a simple LDAP implementation that should work
- good as a test server.
-
- If the LDAP is not available, the tests that need it will be skipped.
-
- Running Redmine.pm tests
- ========================
-
- (work in progress)
-
- Running the tests for the Redmine.pm perl module needs a bit more setup.
- You need an Apache server with mod_perl, mod_dav_svn and Redmine.pm configured.
- See: http://www.redmine.org/projects/redmine/wiki/Repositories_access_control_with_apache_mod_dav_svn_and_mod_perl
-
- You need an empty repository accessible at http://127.0.0.1/svn/ecookbook
- Then, you can run the tests with:
- `ruby test\extra\redmine_pm\repository_subversion_test.rb`
-
- If your svn server is not running on localhost, you can use the
- REDMINE_TEST_DAV_SERVER environment variable to specify another host.
-
- Running Capybara tests
- ======================
-
- You need to have Chrome installed and available in your PATH.
- Chromedriver is managed by the `webdrivers` gem (https://rubygems.org/gems/webdrivers)
-
- Capybara tests can be run with:
- `rails test:system`
-
- The following environment variables can be used to configure your system tests setup:
- `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
- `CAPYBARA_SERVER_PORT`: configure server port
- `SELENIUM_REMOTE_URL`: remote Selenium URL
- `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
- `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:
- `export GOOGLE_CHROME_OPTS_ARGS="headless,disable-gpu,no-sandbox,disable-dev-shm-usage"`
-
- One use case of these variables is to run the system tests on a remote Selenium/ChromeDriver (eg: Docker).
-
- Running RuboCop, a static code analyzer
- =======================================
-
- RuboCop allows you to find out if the code violates the Ruby Style Guide.
- Checking with RuboCop is recommended when you write patches.
-
- You can run RuboCop with:
- `bundle exec rubocop [file ...]`
-
- Running Stylelint, a static code analyzer for CSS files
- =======================================
-
- You need to have NodeJS and Yarn installed and available in your PATH:
- https://nodejs.org/en/download/package-manager/
- https://legacy.yarnpkg.com/lang/en/docs/install/#mac-stable
-
- Install Stylelint:
- `yarn install`
-
- You can run Stylelint with:
- `node_modules/.bin/stylelint "public/stylesheets/**/*.css"`
|