r5449: *** empty log message ***
[xlunit.git] / example.lisp
1 ;;;; -*- Mode: LISP; Syntax: ANSI-Common-Lisp; Base: 10 -*-
2 ;;;; *************************************************************************
3 ;;;; FILE IDENTIFICATION
4 ;;;;
5 ;;;; Name:        example.lisp
6 ;;;; Purpose:     Example file for XLUnit
7 ;;;; Authors:     Kevin Rosenberg and Craig Brozefsky
8 ;;;;
9 ;;;; $Id: example.lisp,v 1.3 2003/08/04 09:50:33 kevin Exp $
10 ;;;; *************************************************************************
11
12 (defpackage #:xlunit-example
13   (:use #:cl #:xlunit)
14   (:export #:math-test-suite))
15
16 (in-package #:xlunit-example)
17
18 ;;; First we define some basic fixtures that we are going to need to
19 ;;; perform our tests.  A fixture is a place to hold data we need
20 ;;; during testing.  Often there are many test cases that use the same
21 ;;; data.  Each of these test cases is an instance of a test-fixture.
22
23 (defclass math-fixture (test-fixture)
24   ((numbera :accessor numbera)
25    (numberb :accessor numberb))
26   (:documentation "Test fixture for math testing"))
27
28 ;;; Then we define a setup method for the fixture.  This method is run
29 ;;; prior to perfoming any test with an instance of this fixture.  It
30 ;;; should perform all initialization needed, and assume that it is starting
31 ;;; with a pristine environment, well to a point, use your head here.
32
33 (defmethod setup ((fix math-fixture))
34   (setf (numbera fix) 2)
35   (setf (numberb fix) 3))
36
37 ;;; Then we define a teardown method, which should return the instance
38 ;;; to it's original form and reset the environment.  In this case
39 ;;; there is little for us to do since the fixture is quite static.
40 ;;; In other cases we may need to clear some database tables, or
41 ;;; otherwise get rid of state built up while perofmring the test.
42 ;;; Here we just return T.
43
44 (defmethod teardown ((fix math-fixture))
45   t)
46
47 ;;; Once we hav a fixture we can start defining method on it which
48 ;;; will perform tests.  These methods should take one argument, an
49 ;;; instance of the fixture.  The method performs some operation and
50 ;;; then performs some tests to determine if the proper behavior
51 ;;; occured.  If there is a failure to behave as excpeted the method
52 ;;; raises a test-failure object by calling the method FAILURE.  This
53 ;;; is much like calling ERROR in that it stops processing that
54 ;;; method.  Each method should only check for one aspect of behavior.
55 ;;; This way triggering one failure would not result in another
56 ;;; behavior check from being skipped.  It does not matter what these
57 ;;; methods return
58
59 (defmethod test-addition ((test math-fixture))
60   (let ((result (+ (numbera test) (numberb test))))
61     (test-assert (= result 5))))
62
63 (defmethod test-subtraction ((test math-fixture))
64   (let ((result (- (numberb test) (numbera test))))
65     (assert-equal result 1)))
66
67 ;;; This method is meant to signal a failure
68 (defmethod test-subtraction-2 ((test math-fixture))
69   (let ((result (- (numbera test) (numberb test))))
70     (assert-equal result 1)))
71
72 ;;;; Finally we can run our test suite and see how it performs.
73 (text-testrunner (make-test-suite 'math-fixture))
74