An Introduction To Software Development - Test Driven Development

An Introduction To Software

Development Using Python

Spring Semester, 2014

Class #16:

Test Driven

Development

New Idea: Test First, Not Last!

• Don’t try to go back and work testing into a completed project.

• Instead, build support for testing into the project from the start.

• New idea: Test Driven Design (TDD) – create code with testing in mind from the start.

Pay with

Visa

Pay with

MCPay with

Paypal

3

3

5

Pay with Visa / MC / Paypal

Test First…

• The “Pay With Visa / Mastercard / PayPal” user story is going to be broken into tasks.

• If we are going to test first, then we need to look at our first task

• If we jump right into creating code, then we’ll be right back where we’ve been doing testing last.

Pay with

Visa

Pay with

MCPay with

Paypal

3

3

5

Pay with Visa / MC / Paypal

Analyze The Task

• First we have to break this task down. For this task we’ll have to:

– Represent the Order Information: We’ll have to capture the customer’s name, what they are ordering, and the cost

– Represent the Credit Card Information: We’ll need the credit card info, and their secret card number.

– Represent Receipt Information: We’ll have to capture the confirmation number, the final cost, as well as the date of the transaction.

Pay with

Visa

3

Create The Test First!

• Write a test case first!

• Start with the order information part of the task.

• Use your test framework to create a test for the “Pay with Visa” functionality.

Image Credit: www.canstockphoto.com

Welcome To TDD!

• When you are creating test cases before you write code and then letting those test cases drive how you create your code, you are using Test Driven Development (TDD).

• TDD is a formal term that is used to describe the process of testing from the outset of development.

• This means that you write every line of code specifically as a response to your tests.

Image Credit: revistanautilus.ro

How To Write A Test Case

• Your first step needs to be to determine just exactly what needs to be tested.

• Since this is fine grained testing, testing at the unit testing level, you should start with a small test.

• Determine what the smallest test that you could write would be that uses the order information that you’ll be storing as a part of the first task?

Image Credit: antoni.w-w.pl

Test Case Creation Secrets

• You have no code! You are writing your tests first.

• There is no way that this test should pass the first time that you run it.

• The test probably won’t even compile. However, that’s ok…

• Remember, at first your test case…fails miserably.

Image Credit: www.clipartpanda.com

TDD Rule #1

• TDD Rule #1: Your test should always fail before you implement any code.

• You want your tests to fail when you first write them.

• The point of the test is to establish a measurable success.

• Because your test is failing, now it’s clear what you have to do to make sure that test passes.

Image Credit: www.fs.usda.gov

Your Next Step…

• Write the simplest code just to get this test to pass.

• This is called “… getting your tests to green.”

• Green refers to a green bar that many automated test case runners display when all tests pass. If any test fails, a red bar is displayed.

• TDD Rule #2: Implement the simplest code possible to make your test cases pass.

Image Credit: www.clipartpanda.com

The YAGNI Principal

• Test-Driven Development is about doing the simplest thing that you can do in order to get your test case to pass.

• Do not add anything that you MIGHT NEED in the future.

• If you do need something in the future, you’ll write a test case for it and then you’ll write code to pass that test case.

• Focusing on small bits of code is the key to test-driven development.

• YAGNI: “Ya ain’t going to need it”

Image Credit: www.fotosearch.com

3 Steps To Test Driven Development

• Red: Your Test Fails

– Write a test to check whatever functionality you are going to write.

– It will fail because you have not yet implemented that functionality.

– This is the red stage because your testing GUI will show the test in red (failing).

• Green: Your Test Passes– Implement the functionality to get that test to pass

– Write the simplest code possible to get the test to pass.

– This is the green stage.

• Refactor: Clean up – duplication, ugly code, old code, etc.– After your test passes, go back in and clean up things that you noticed while

implementing your code.

– This is the refactor stage.

– Next, go on to create the next test.

Pay with

Visa

3

Pay with Visa / MC / Paypal

Image Credit: cliparts.co

Exercise: Pay With Visa

• Represent the Order Information: We’ll have to capture the customer’s name, what they are ordering, and the cost

– What tests can we create for the order information task?

– What will be the minimal amount of code that we can implement to pass these tests?

Image Credit: presstigeprinting.com

In TDD, Tests Drive Your Implementation

• TDD drives your implementation all the way through development.

• By writing tests before code, you have to focus on the functionality right off the bat.

• What is the code that you are creating supposed to do?

Image Credit: www.clipartpanda.com

Good TDD Habits

• Each test should verify only one thing– Make each test only test one thing

• Avoid duplicate test code– Just like you avoid duplicate code, avoid duplicate tests.

• Keep your tests in a mirror directory of your source code– You will be creating a lot of test cases

– Keep your tests in a separate subdirectory on the same level as your source code and with the same directory structure.

– This will make life easier for your build scripts

Image Credit: www.dreamstime.com

Completing A Task

• You’ve got all the tests that you need and they all pass.

• When your tests pass, move on!

• Different task, use the same process…

Image Credit: cliparts.co

Dependencies Are A Bad Thing When It Comes To Testing

• Simple code means that you can break things up and test parts of your code one thing at a time.

• Dependencies: code that depends on something that is external to your code (like a database or an interface)

• Dependencies make it hard to test one thing at a time

• Your job is to figure out a way to test your code independent of the dependencies

Image Credit: blogs.msdn.com

First You Have To Find Your DependenciesPay with

Visa

3

– Represent the Order Information: • Get card owner’s name• Get card owner’s address

– Represent the Credit Card Information:

• Get credit card number• Get secret confirmation number

– Represent Receipt Information: • Provide confirmation number• The final cost• Date of the transaction.

NameAddress

CC #Secret #

CC #Secret #

Conf #CostDate

Conf #CostDate

Your

Program

Your

Program

Your

Program

Credit

Card

Paper

Need To Create Testing Interfaces

NameAddress

CC #Secret #

DummyInput

Conf #CostDate

DummyOutput

Your

Program

Your

Program

Your

Program

• Need to hide how our application gets and gives its data

• Change how this works depending on if we are conducting testing or running in production

• We want to have two different ways of passing the information that we want

• Our program does not have to know which one it is using

DummyInput

Code

Stub

Code

Stub

Image Credit: www.clker.com

What Would This Look Like In Python?

#

# Constants used in this program

runningTest = 1 # 0 = in production, 1 = testing being done

#

# Collect personal information from credit card owner

if (runningTest == 0) :

lastName = input("Please enter last name: ")

firstName = input("Please enter first name: ")

middleInitial = input("Please enter the middle initial: ")

streetAddress = input("Please enter street address: ")

city = input("Please enter city: ")

state = input("Please enter state: ")

zip = input("Please enter zip: ")

else:

lastName = "Johnson"

firstName = "Fred“

middleInitial = "N"

streetAddress = “2763 Filibuster Drive”

city = "Lakeland"

state = “FL”

zip = "37643"

Image Credit: 4vector.com

What Does Testing First Buy Us?

• Testing produces better code

• Create well-organized code– Simpler code

– Nothing that is not absolutely required

• Code that always does the same thing– Production code does the same thing as testing code

– We are writing production code all the time

• Code is loosely coupled– Tightly coupled code is brittle and breaks easily

– Our code will be broken into a loosely coupled flexible system

Image Credit: www.fotosearch.com

What Kind Of Tests Do We Have To Write Now?

NameAddress

CC #Secret #

CC #Secret #

Conf #CostDate

Conf #CostDate

Your

Program

Your

Program

Your

Program

Credit

Card

Paper

Name too long

Name too short

Illegal name characters

Street too long

Street too short

Illegal street characters

No name

No street

No CC #

CC # too long

CC # too short

No secret #

Secret # too long

Secret # too short

Wrong secret #

Valid name

Valid street

Valid CC #

Valid secret #

Valid conf #

Valid cost

Valid date

22

Tests

Things NOT To Do When Writing Code

Testing Nothing:

You can write a lot of test code that doesn’t really

test anything. Could place a credit card order and

then not test the cost printed on the final receipt.

Don’t Test Your Data:

It can be all too easy to create test cases that test

the fake data that you’ve created and not the code

that you’ve written.

Get Rid Of Scraps:

The system state that your testing starts in is very

important. You need to always clean up and start

in the same state each time. Image Credit: alexrister1.wordpress.com

So Just Exactly What Have We Learned About Testing?

1. Always write the test before you write the code.

2. Make the test fail first, then write the simplest code that will make the test pass

3. Each test should only test one thing

4. Once your tests pass, you can then clean up your code (refactor)

5. When you are out of tests to write, you’re done!

Image Credit: clipart-finder.com

What We Covered Today

1. Test first, not last!

2. Test-Driven Development

3. TDD Rule #1: Your test should always fail before you implement any code.

4. TDD Rule #2: Implement the simplest code possible to make your test cases pass.

Image Credit: http://www.tswdj.com/blog/2011/05/17/the-grooms-checklist/

What We’ll Be Covering Next Time

1. Ending an iteration

Image Credit: http://merchantblog.thefind.com/2011/01/merchant-newsletter/resolve-to-take-advantage-of-these-5-e-commerce-trends/attachment/crystal-ball-fullsize/