|
a/pyforge/docs/install.rst |
|
b/pyforge/docs/install.rst |
|
... |
|
... |
| 127 |
This server routes messages from email addresses to plugins in the forge::
|
127 |
This server routes messages from email addresses to plugins in the forge::
|
| 128 |
|
128 |
|
| 129 |
(anvil)~/src/forge/pyforge$ paster smtp_server development.ini
|
129 |
(anvil)~/src/forge/pyforge$ paster smtp_server development.ini
|
| 130 |
|
130 |
|
| 131 |
SOLR server
|
131 |
SOLR server
|
| 132 |
This is our search and indexing server. We can use the example schema directly from the
|
132 |
This is our search and indexing server. We have a custom config in
|
| 133 |
SOLR download::
|
133 |
~/src/forge/solr_config::
|
| 134 |
|
134 |
|
| 135 |
(anvil)~/<path_to_solr>/example$ java -jar start.jar
|
135 |
(anvil)~/<path_to_solr>/example$ java -Dsolr.solr.home=~/src/forge/solr_config -jar start.jar
|
| 136 |
|
136 |
|
| 137 |
TurboGears application server
|
137 |
TurboGears application server
|
| 138 |
This is the main application that will respond to web requests. We'll get into
|
138 |
This is the main application that will respond to web requests. We'll get into
|
| 139 |
details later.
|
139 |
details later.
|
| 140 |
|
140 |
|
|
... |
|
... |
| 157 |
Part of the base system includes the test_admin and test_user accounts. The
|
157 |
Part of the base system includes the test_admin and test_user accounts. The
|
| 158 |
password for both accounts is `foo`. The `test` project has several plugins
|
158 |
password for both accounts is `foo`. The `test` project has several plugins
|
| 159 |
already configured; to configure more, you can visit the `Admin` plugin
|
159 |
already configured; to configure more, you can visit the `Admin` plugin
|
| 160 |
(accessible in the top navigation bar when inside the `test` project).
|
160 |
(accessible in the top navigation bar when inside the `test` project).
|
| 161 |
|
161 |
|
|
|
162 |
Running the Tests
|
|
|
163 |
---------------------------------
|
|
|
164 |
|
|
|
165 |
The test setup is a little bit different from the dev/production setup so as not
|
|
|
166 |
to create conflicts between test data and development data. This section will
|
|
|
167 |
tell you how to set up your test environment.
|
|
|
168 |
|
|
|
169 |
mongod
|
|
|
170 |
We'll need a test MongoDB server to keep from stomping on our development data::
|
|
|
171 |
|
|
|
172 |
(anvil)~/src$ mkdir -p ~/var/mongodata-test
|
|
|
173 |
(anvil)~/src$ mongod --port 27108 --dbpath ~/var/mongodata-test
|
|
|
174 |
|
|
|
175 |
RabbitMQ
|
|
|
176 |
Here, we'll set up a second virtual host for testing. We also need to set up
|
|
|
177 |
the RabbitMQ queues using reactor_setup::
|
|
|
178 |
|
|
|
179 |
(anvil)~/src$ sudo rabbitmqctl add_vhost vhost_testing
|
|
|
180 |
(anvil)~/src$ sudo rabbitmqctl set_permissions -p vhost_testing testuser "" ".*" ".*"
|
|
|
181 |
(anvil)~/src$ cd forge/pyforge
|
|
|
182 |
(anvil)~/src/forge/pyforge$ paster reactor_setup test.ini
|
|
|
183 |
|
|
|
184 |
SOLR server
|
|
|
185 |
We are using the multicore version of SOLR already, so all the changes to use
|
|
|
186 |
core1 (the testing core) rather than core0 (the dev core) are encapsulated in
|
|
|
187 |
test.ini.
|
|
|
188 |
|
|
|
189 |
To actually run the tests, just go to the plugin directory you wish to test (or
|
|
|
190 |
to the pyforge directory) and type::
|
|
|
191 |
|
|
|
192 |
(anvil)~/src/forge/pyforge$ nosetests
|
|
|
193 |
|
|
|
194 |
Some options you might find useful for nosetests:
|
|
|
195 |
|
|
|
196 |
--pdb
|
|
|
197 |
Drops into a PDB prompt on unexpected exceptions ("errors" in unittest
|
|
|
198 |
terminology)
|
|
|
199 |
|
|
|
200 |
--pdb-fail
|
|
|
201 |
Drops into a PDB prompt on AssertionError exceptions in tests ("failures" in unittest
|
|
|
202 |
terminology)
|
|
|
203 |
|
|
|
204 |
-s
|
|
|
205 |
Do *not* capture stdout. This is essential if you have embedded pdb
|
|
|
206 |
breakpoints in your test code. (Otherwise, you will not see the prompt; your
|
|
|
207 |
test will just mysteriously hang forever.)
|
|
|
208 |
|
|
|
209 |
-v
|
|
|
210 |
Print the name of the test as it runs. This is useful if the test suite takes a while
|
|
|
211 |
to run and you want to let it continue to run while you begin debugging the
|
|
|
212 |
first (few) failures.
|
|
|
213 |
|
|
|
214 |
|
| 162 |
Happy hacking!
|
215 |
Happy hacking!
|