| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192 | 
							- ==========
 - Test suite
 - ==========
 - 
 - Running tests
 - -------------
 - 
 - Oscar uses a nose_ testrunner which can be invoked using::
 - 
 -     $ ./runtests.py
 - 
 - .. _nose: http://nose.readthedocs.org/en/latest/
 - 
 - To run a subset of tests, you can use filesystem or module paths.  These two
 - commands will run the same set of tests::
 - 
 -     $ ./runtests.py tests/unit/order
 -     $ ./runtests.py tests.unit.order
 - 
 - To run an individual test class, use one of::
 - 
 -     $ ./runtests.py tests/unit/order:TestSuccessfulOrderCreation
 -     $ ./runtests.py tests.unit.order:TestSuccessfulOrderCreation
 - 
 - (Note the ':'.)
 - 
 - To run an individual test, use one of::
 - 
 -     $ ./runtests.py tests/unit/order:TestSuccessfulOrderCreation.test_creates_order_and_line_models
 -     $ ./runtests.py tests.unit.order:TestSuccessfulOrderCreation.test_creates_order_and_line_models
 - 
 - Testing against different setups
 - --------------------------------
 - 
 - To run all tests against multiple versions of Django and Python, use tox_::
 - 
 -     $ tox
 - 
 - You need to have all Python interpreters to test against installed on your 
 - system. All other requirements are downloaded automatically.
 - 
 - .. _tox: http://tox.readthedocs.org/en/latest/
 - 
 - Kinds of tests
 - --------------
 - 
 - Tests are split into 3 folders:
 - 
 - * unit - These are for tests that exercise a single unit of functionality, like
 -   a single model.  Ideally, these should not write to the database at all - all
 -   operations should be in memory.
 - 
 - * integration - These are for tests that exercise a collection or chain of
 -   units, like testing a template tag.  
 - 
 - * functional - These should be as close to "end-to-end" as possible.  Most of
 -   these tests should use WebTest to simulate the behaviour of a user browsing
 -   the site.
 - 
 - Naming tests
 - ------------
 - 
 - Oscar's testrunner uses the progressive_ plugin when running all tests, but uses
 - the spec_ plugin when running a subset.  It is a good practice to name your test
 - cases and methods so that the spec output reads well.  For example::
 - 
 -     $ ./runtests.py tests/unit/offer/benefit_tests.py:TestAbsoluteDiscount
 -     nosetests --verbosity 1 tests/unit/offer/benefit_tests.py:TestAbsoluteDiscount -s -x --with-spec
 -     Creating test database for alias 'default'...
 - 
 -     Absolute discount
 -     - consumes all lines for multi item basket cheaper than threshold
 -     - consumes all products for heterogeneous basket
 -     - consumes correct quantity for multi item basket more expensive than threshold
 -     - correctly discounts line
 -     - discount is applied to lines
 -     - gives correct discount for multi item basket cheaper than threshold
 -     - gives correct discount for multi item basket more expensive than threshold
 -     - gives correct discount for multi item basket with max affected items set
 -     - gives correct discount for single item basket cheaper than threshold
 -     - gives correct discount for single item basket equal to threshold
 -     - gives correct discount for single item basket more expensive than threshold
 -     - gives correct discounts when applied multiple times
 -     - gives correct discounts when applied multiple times with condition
 -     - gives no discount for a non discountable product
 -     - gives no discount for an empty basket
 - 
 -     ----------------------------------------------------------------------
 -     Ran 15 tests in 0.295s
 - 
 - .. _progressive: http://pypi.python.org/pypi/nose-progressive/
 - .. _spec: http://darcs.idyll.org/~t/projects/pinocchio/doc/#spec-generate-test-description-from-test-class-method-names
 
 
  |