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
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
Local Development
-----------------
Development environments can be set of using the setup.py files in the
projects you wish to work on. The easiest approach is to use python-virtualenv.
Since most projects require the ci-utils project, that should almost always
get setup first.
Another quick way to get started is to look at the tarmac.sh script which
sets up a quick environment to run component testing under.
There are two types of services written in this project, Django and Restish.
Development varies slightly between the two.
Ticket System
~~~~~~~~~~~~~
::
# setup the ticket system project
sudo apt-get install python-virtualenv libssl-dev libapt-pkg-dev libffi-dev python-dev
./testing/venv.py /tmp/venv
. /tmp/venv/bin/activate
./ci-utils/setup.py develop
./ticket_system/setup.py develop
Unit-testing can be done with::
# via setuptools
./ticket_system/setup.py test
# directly via django
./manage.py test # this tests everything (including django)
./manage.py test ticket # just test the project
./manage.py test ticket.APIUpdateSubTicketStatuses #test one class
./manage.py test ticket.APIUpdateSubTicketStatuses.test_delete_subticket_not_allowed # test one method
CLI
~~~
::
# setup the CLI project
./testing/venv.py /tmp/venv
. /tmp/venv/bin/activate
./ci-utils/setup.py develop
Unit-testing can be done with::
./cli/setup.py test
Restish
~~~~~~~
::
./testing/venv.py /tmp/venv
. /tmp/venv/bin/activate
./ci-utils/setup.py develop
./branch-source-builder/setup.py develop
Unit-testing can be done a couple of ways:
# using setuptools:
./image-builder/setup.py test
# python unittest directly
python -m unittest discover -s branch-source-builder
Running under the python wsgi server can be done with::
./branch-source-builder/bsbuilder/wsgi.py
Running under gunicorn can be done with::
# need gunicorn:
pip install gunicorn
# TIP: by setting max-requests=1 you can make changes to the source code
# and they'll be picked up in the next http request you make!!
gunicorn --max-requests 1 bsbuilder.wsgi:app
Juju Testing
------------
Each service should include a juju-deployer config under the juju-deployer
directory.
To deploy them all, run `./juju-deployer/deploy`
Install pre-requisites:
$ sudo apt-get install juju juju-deployer python-httplib2
Configure juju for canonistack (or whatever you feel is appropriate), make
sure you select the region there (see OS_REGION_NAME/NOVA_REGION):
$ . ~/.canonistack/novarc
Create a proper ~/.juju/environments.yaml, example:
environments:
## https://juju.ubuntu.com/docs/config-openstack.html
lcy02:
type: openstack
admin-secret: <your admin secret, juju can auto-create it>
# Globally unique swift bucket name
control-bucket: <you control-bucket secret, juju can auto-create it>
# Usually set via the env variable OS_REGION_NAME, but can be specified here
region: lcy02
$ juju bootstrap --constraints="mem=1G"
Get the IP address of the juju state server from 'nova list --name machine-0':
$ nova list --name machine-0 --fields networks
+--------------------------------------+-------------------------+
| ID | Networks |
+--------------------------------------+-------------------------+
| 0463d358-750c-4fc4-b38b-a618e2e7d034 | canonistack=10.55.32.64 |
+--------------------------------------+-------------------------+
Start sshuttle in the foreground from a different terminal where you've sourced your credentials (we need a way to get that in a more script friendly way):
$ sshuttle -r ubuntu@10.55.32.64 10.55.0.0/16
You'll need to interrupt this command once you're run 'juju destroy-environment' to ensure you didn't leave pending connections to juju instances that should not exist anymore.
Running all tests
-----------------
Run all tests (unit and integration) with the following command:
$ JUJU_ENV=<env_name> ./run-tests [regexp]
It will build and deploy charms if necessary for the selected tests.
You can specify test name regexps like '^tests.'.
Also note that it will leave deployed instances behind (which are useful for subsequent test runs).
Running some tests
------------------
'run-tests' uses regexps to select tests.
A single test (note the '^' and '$' anchors to ensure a single test is
selected:
$ ./run-tests ^testing.test_style.TestPep8.test_pep8_conformance$
All the tests defined under a given directory:
$ ./run-tests ^cli
All style tests:
$ ./run-tests test_style
'^.*\.test_style\..*$' is pedantically more precise but in practice the
simplest form above is enough.
Several subsets to cover all tests related to the test runner component:
$ ./run-tests ^test_runner ^tests.test_test_runner
Excluding tests:
$ ./run-tests -X ^tests
will run all tests except the ones under the ./tests directory (which are
known to require a deployment and to be far slower than the others).
|