← Back to branch summary

~ubuntu-branches/ubuntu/raring/horizon/raring

« back to all changes in this revision

Viewing changes to doc/source/topics/testing.rst

  • Committer: Package Import Robot
  • Author(s): Chuck Short, Adam Gandelman, Chuck Short
  • Date: 2012-11-23 08:49:14 UTC
  • mfrom: (1.1.22)
  • Revision ID: package-import@ubuntu.com-20121123084914-95m0mzmiicdw64ti
Tags: 2013.1~g1-0ubuntu1
[ Adam Gandelman ]
* debian/patches/add_juju_settings_pannel.patch: Disable during
  Grizzly dev. cycle. 

[ Chuck Short ]
* New upstream relase.
* Refreshed patches.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/source/topics/testing.rst
170
170
necessary.
171
171
 
172
172
To that end, Horizon includes several custom assertions to make these tasks
173
 
easier. :meth:`~horizon.test.TestCase.assertNoFormErrors`,
174
 
:meth:`~horizon.test.TestCase.assertMessageCount`, and
175
 
:meth:`~horizon.test.TestCase.asertNoMessages` all exist for exactly these
176
 
purposes. Moreover, they provide useful output when things go wrong so you're
177
 
not left scratching your head wondering why your view test didn't redirect
178
 
as expected when you posted a form.
 
173
easier. :meth:`~horizon.test.helpers.TestCase.assertNoFormErrors`,
 
174
:meth:`~horizon.test.helpers.TestCase.assertMessageCount`, and
 
175
:meth:`~horizon.test.helpers.TestCase.asertNoMessages` all exist for exactly
 
176
these purposes. Moreover, they provide useful output when things go wrong so
 
177
you're not left scratching your head wondering why your view test didn't
 
178
redirect as expected when you posted a form.
179
179
 
180
180
.. _debugging_unit_tests:
181
181
 
185
185
Tips and tricks
186
186
---------------
187
187
 
188
 
#. Use :meth:`~horizon.test.TestCase.assertNoFormErrors` immediately after
189
 
   your ``client.post`` call for tests that handle form views. This will
 
188
#. Use :meth:`~horizon.test.helpers.TestCase.assertNoFormErrors` immediately
 
189
   after your ``client.post`` call for tests that handle form views. This will
190
190
   immediately fail if your form POST failed due to a validation error and
191
191
   tell you what the error was.
192
192
 
193
 
#. Use :meth:`~horizon.test.TestCase.assertMessageCount` and
194
 
   :meth:`~horizon.test.TestCase.asertNoMessages` when a piece of code is
195
 
   failing inexplicably. Since the core error handlers attach user-facing
 
193
#. Use :meth:`~horizon.test.helpers.TestCase.assertMessageCount` and
 
194
   :meth:`~horizon.test.helpers.TestCase.asertNoMessages` when a piece of code
 
195
   is failing inexplicably. Since the core error handlers attach user-facing
196
196
   error messages (and since the core logging is silenced during test runs)
197
197
   these methods give you the dual benefit of verifying the output you expect
198
198
   while clearly showing you the problematic error message if they fail.
270
270
This one is the opposite of the unexpected method call. This one means you
271
271
tol mox to expect a call and it didn't happen. This is almost always the
272
272
result of an error in the conditions of the test. Using the
273
 
:meth:`~horizon.test.TestCase.assertNoFormErrors` and
274
 
:meth:`~horizon.test.TestCase.assertMessageCount` will make it readily apparent
275
 
what the problem is in the majority of cases. If not, then use ``pdb`` and
276
 
start interrupting the code flow to see where things are getting off track.
 
273
:meth:`~horizon.test.helpers.TestCase.assertNoFormErrors` and
 
274
:meth:`~horizon.test.helpers.TestCase.assertMessageCount` will make it readily
 
275
apparent what the problem is in the majority of cases. If not, then use ``pdb``
 
276
and start interrupting the code flow to see where things are getting off track.