sogo/Tests/Integration
Wolfgang Sourdeau 320e9256d1 Monotone-Parent: 044582e9ad4ddb9d86e36c14f35c91195c979b7c
Monotone-Revision: 8f6b1948a4de37d255b2c1ab1d3f1baa780f455d

Monotone-Author: wsourdeau@inverse.ca
Monotone-Date: 2010-05-06T19:30:14
Monotone-Branch: ca.inverse.sogo
2010-05-06 19:30:14 +00:00
..
all.py See ChangeLog 2010-01-24 20:40:12 +00:00
config.py.in See ChangeLog 2010-01-24 20:40:12 +00:00
preferences.py See ChangeLog 2010-01-24 20:40:12 +00:00
propfind.py See ChangeLog 2010-01-24 20:40:12 +00:00
README See ChangeLog 2010-01-24 20:40:12 +00:00
test-caldav-scheduling.py Monotone-Parent: 044582e9ad4ddb9d86e36c14f35c91195c979b7c 2010-05-06 19:30:14 +00:00
test-config.py See ChangeLog 2010-01-24 20:40:12 +00:00
test-davacl.py Monotone-Parent: 8b8ee97bac3348f28840940fdf58d205587d035f 2010-02-02 21:35:12 +00:00
test-ical.py See ChangeLog 2010-01-24 20:40:12 +00:00
test-maildav.py Monotone-Parent: 15cce56fb2a02fa6d50d7fd1d75ccff373d6108e 2010-04-09 18:30:09 +00:00
test-webdav.py Monotone-Parent: 86ef295932bd121e7b8a29072f0a498b9bc26089 2010-04-26 15:15:42 +00:00
test-webdavlib.py See ChangeLog 2010-01-24 20:40:12 +00:00
test-webdavsync.py See ChangeLog 2010-01-24 20:40:12 +00:00
utilities.py Monotone-Parent: 44fc3e25d97f062f2add05e5d39a9ffb983d11ca 2010-04-09 18:31:17 +00:00
webdavlib.py Monotone-Parent: 86ef295932bd121e7b8a29072f0a498b9bc26089 2010-04-26 15:15:42 +00:00

setup
-----

(you need "python-simplejson", "python-xml", "python-vobject" and "python-m2crypto"
 in order to run the scripts on Debian)

1) copy config.py.in to config.py (make sure to never EVER add it to monotone)
2) edit config.py to suit your environment
3) run the test scripts

runnable scripts
----------------

all.py - run all scripts below at once
test-webdavsync.py - explicit
test-davacl.py - dav acl tests for calendar and addressbook modules

other scripts
-------------

propfind.py - a sample implementation of a PROPFIND request using webdavlib

* developers
------------

- Test methods are always prefixed with "test". Sometimes, it's easier to
track down a problem by enabling only one test at a time. One possible method
is to replace "def test" with "def xtest" and replace it back when the
problems are solved.

- Test failures start with "FAIL:". Those are the ones that indicate possible
  bugs in the application, if the test is itself known to work.
  For example like this:

======================================================================
FAIL: 'modify' PUBLIC, 'view all' PRIVATE, 'view d&t' confidential
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./davacl.py", line 75, in testModifyPublicViewAllPrivateViewDConfidential
    self._testRights({ "pu": "m", "pr": "v", "co": "d" })
  File "./davacl.py", line 119, in _testRights
    self._testCreate(rights)
  File "./davacl.py", line 165, in _testCreate
    exp_code)
  File "./davacl.py", line 107, in _putEvent
    % (exp_status, put.response["status"]))
AssertionError: event creation/modification: expected status code '403' (received '201')

- Test errors start with "ERRORS" and most likely indicate a bug in the test
  code itself.

- Always set a doc string on the test methods, especially for complex test
  cases.

- When writing tests, be aware that contrary to unit tests, functional tests
  often imply a logical order between the different steps.