chapter 8 testing the programs. chapter 8 learning objectives be able to … define different types...

Post on 17-Jan-2016

224 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Chapter 8

Testing the Programs

Chapter 8 Learning Objectives Be able to …

Define different types of faults and how to classify them

Define the purpose of testing

Discussion Questions

What are some different types of program faults?

What is the difference between a program fault versus a program failure?

Discussion Questions

Why do we test for program faults?

Who does the testing?

Chapter 8 Learning Objectives Be able to …

Describe unit testing

Describe integration testing

Explain the difference between them

Unit Testing unit testing is a procedure used to validate

that individual units of source code are working properly

A unit is the smallest testable part of an application In procedural programming a unit is a function,

procedure, subroutine, etc. In object-oriented programming, a unit is a method

The goal is to show that the individual parts are correct

Integration Testing

B

A

E D C

F G I H K J

Top-down testingBottom-up testingSandwich testingBig-bang testing

Discussion Question

What are some differences between integration testing of

object-oriented programs versus

procedural programs?

OO Integration Testing Strategies

Thread-based testing: integrates classes required to respond to event

Use-based testing: integrates classes required by one use case

Cluster testing: integrates classes required to demonstrate one collaboration

Discussion Question

How do we know when we can stop testing?

Unit Testing with xUnit Test fixture : a class that contains one or more

test methods Test method : a method that executes a

specific test Test runner : an application that finds and

executes test methods on test fixtures Assertion : a Boolean expression that

describes what must be true when some action has been executed

public class Account{ private double balance = 0.0; public Account(double b) { balance = b; } public double Balance { get { return balance; } }

public void Withdraw(double amount) { if (balance >= amount) balance -= amount; } public void Deposit(double amount) { // TO DO }}

Class to be unit tested

[TestClass()] public class AccountTest {

...

[TestMethod()] public void WithdrawTestWithSufficientFunds() { Account acct = new Account(100.0); acct.Withdraw(50.00); Assert.AreEqual(50.0, acct.Balance); }

[TestMethod()] public void WithdrawTestWithInsufficientFunds() { Account acct = new Account(100.0); acct.Withdraw(150.00); Assert.AreEqual(100.0, acct.Balance); }

Test Fixture

Test Runner

Test-Driven Development

Never write a single line of code unless you have a failing automated test

Refactor to eliminate duplication

Red/Green/Refactor1. Write the test code2. Compile the test code

(It should fail because you haven’t implemented anything yet.)

3. Implement just enough to compile.4. Run the test and see it fail.5. Implement just enough to make the test pass.6. Run the test and see it pass.7. Refactor for clarity and to eliminate duplication.8. Repeat from the top.

top related