An Introduction To Software Development - Test Driven Development
-
Upload
blue-elephant-consulting -
Category
Education
-
view
88 -
download
3
Transcript of 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/