1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
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: https://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:
`npx stylelint "app/assets/stylesheets/**/*.css"`
|
