Testing Using the SUnit Framework Testing and XP

Testing Using the SUnit Framework

Testing and XP • Testing is an integral part of development to practitioners of e. Xterme Programming (XP). • Their “test first” philosophy means that a test suite is developed for a class before any code is written. • One recommendation: testing is a good place to start adopting XP practices.

Why a test suite first? • Instances of a class provides services to other objects. • The set of services can be thought of as a “contract” between the class and its clients. • A test suite serves as an operational way to define the contract.

What does a test suite look like? If a class is defined by its services, the test suite must attempt to “prove” that all of the services work. – At least one test to show that each service works correctly – Tests as necessary to show erroneous cases are handled adequately Think equivalence classes!

What does a test suite look like? A test suite is thus potentially a lot of tests. • Where should they reside? • How are they managed? • How are they run and evaluated?

The SUnit Framework The XP answer to the previous questions is the SUnit Framework. A framework is a set of classes with a carefully designed structure that work together to provide a service when specialized through inheritance. See “Simple Smalltalk Testing: With Patterns” by Kent Beck: http: //www. xprogramming. com/testfram. htm

A “Pattern System” for Writing Tests Pattern Fixture Test Case Check Test Suite Purpose Create a common test fixture. Create the stimulus for a test case. Check the response for a test case. Aggregate Test. Cases.

Creating Fixtures and Test Cases • Start with a single configuration whose behavior is predictable. As you get more experience with your software, you will be able to add to the list of configurations. • Such a configuration is called a "fixture". Examples of fixtures are: Fixture Predictions 1. 0 and 2. 0 Easy to predict answers to arithmetic problems Network connection to Responses to network packets a known machine #() and #(1 2 3) Results of sending testing messages

Design a Test Fixture • • • Subclass Test. Case Add an instance variable for each known object in the fixture Override set. Up to initialize the variables Class: Set. Test. Case superclass: Test. Case instance variables: empty full Set. Test. Case>>set. Up empty : = Set new. full : = Set with: #abc with: 5

Test Cases Represent a predictable reaction to a fixture (by a service) as a method: – Add a method to Test. Case subclass – Stimulate the fixture in the method Set. Test. Case>>test. Add empty add: 5. .

Checking Turn checks into a Block evaluating to a Boolean. Send the Block as the parameter to "should: ”: Set. Test. Case>>test. Add empty add: 5. self should: [empty includes: 5] (Set. Test. Case selector: #test. Add) run

The rest … Set. Test. Case>>test. Remove full remove: 5. self should: [full includes: #abc]. self shouldnt: [full includes: 5] Set. Test. Case>>test. Illegal self should: [self error. Signal handle: [: ex | true] do: [empty at: 5. false]] | suite : = Test. Suite named: 'Set Tests'. suite add. Test. Case: (Set. Test. Case selector: #test. Add). suite add. Test. Case: (Set. Test. Case selector: #test. Remove). suite add. Test. Case: (Set. Test. Case selector: #test. Illegal). ^suite

An Object Explorer picture