-
Notifications
You must be signed in to change notification settings - Fork 2k
/
__init__.py
66 lines (47 loc) · 2.56 KB
/
__init__.py
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
'''
Controller tests probably shouldn't use mocking.
.. todo::
Write the tests for one controller, figuring out the best way to write
controller tests. Then fill in this guidelines section, using the first set
of controller tests as an example.
Some things have been decided already:
* All controller methods should have tests
* Controller tests should be high-level tests that work by posting simulated
HTTP requests to CKAN URLs and testing the response. So the controller
tests are also testing CKAN's templates and rendering - these are CKAN's
front-end tests.
For example, maybe we use a webtests testapp and then use beautiful soup
to parse the HTML?
* In general the tests for a controller shouldn't need to be too detailed,
because there shouldn't be a lot of complicated logic and code in
controller classes. The logic should be handled in other places such as
:mod:`ckan.logic` and :mod:`ckan.lib`, where it can be tested easily and
also shared with other code.
* The tests for a controller should:
* Make sure that the template renders without crashing.
* Test that the page contents seem basically correct, or test certain
important elements in the page contents (but don't do too much HTML
parsing).
* Test that submitting any forms on the page works without crashing and
has the expected side-effects.
* When asserting side-effects after submitting a form, controller tests
should user the :func:`ckan.new_tests.helpers.call_action` function. For
example after creating a new user by submitting the new user form, a
test could call the :func:`~ckan.logic.action.get.user_show` action
function to verify that the user was created with the correct values.
.. warning::
Some CKAN controllers *do* contain a lot of complicated logic code. These
controllers should be refactored to move the logic into :mod:`ckan.logic` or
:mod:`ckan.lib` where it can be tested easily. Unfortunately in cases like
this it may be necessary to write a lot of controller tests to get this
code's behavior into a test harness before it can be safely refactored.
'''
import paste.fixture
from pylons.test import pylonsapp
class WsgiAppCase(object):
wsgiapp = pylonsapp
assert wsgiapp, 'You need to run nose with --with-pylons'
# Either that, or this file got imported somehow before the tests started
# running, meaning the pylonsapp wasn't setup yet (which is done in
# pylons.test.py:begin())
app = paste.fixture.TestApp(wsgiapp)