An apology
original talk was going to include kif, but i was not happy with the state of the talk and decided to remove it for the time being.
Free month of swiftcast.TV
Send an e-mail to adamjamesleonard@gmail.com with your e-mail address.
About me
- Rubyist.
- Swifter.
- 9 years of professional programming experience.
- Work for HappyFunCorp
- I help run SwiftCast.TV & SwiftToolbox.
- Wanna-be musician.
- Aspiring life coach.
- @adamjleonard
- http://www.adamjleonard.com.
Goals of this talk
- Learn about Behavior-Driven Development.
- Learn about Test-Driven Development.
- Learn how to leverage Swift and Quick to write beautiful tests.
When talking to developers about testing
What is Behavior-driven development?
What's the point?
- The point of BDD is to ensure that the real business objectives of stakeholders get met by the software we deliver.
HISTORY
BDD was developed by Dan North as a response to the issues he encountered when teaching Test-driven development.
Dan North created the first BDD framework, JBehave. Then he created a story-level BDD framework, RBehave. Which then got integrated in to ???
RSPEC!
What is quick (And nimble)?
Quick
is a BDD (Behavior-driven development) testing framework for Swift and Objective-C.
nimble
is a Matcher framework for Swift.
Writing our first test w quick
But first! What's Test-Driven Development?
- Software development process that relies on the repetition of a very short development cycle
- Write a failing test.
- Write the minimum amount of code to make our test pass.
- Refactor.
- Repeat.
- TDD for short
PROS of TDD
- Better code quality (less coupling and higher cohesion).
- Ability to refactor without fear of breaking things.
- Increased protection from defects such as regressions.
- Tests provide documentation for expected functionality.
- Fast feedback loop.
- Increased confidence.
CONS OF TDD
- Steep learning curve (different tools/methodologies).
- Increased setup costs.
- Slower feature development due to writing associated tests.
- Increased cost of test maintenance as projects progress.
What we will be building first
We will be building a simple Bank Account.
Our Bank Account will have the following functionality
- Deposit money
- Withdrawal money
- Apply overdraft fee
our first test
watching our test fail
IMPlementing our bankAccount class
IMPlementing our bankAccount class
IMPlementing our bankAccount class
Taking a quick look at nimble
nimble gives us matcheRS for our expectations
- to - Expect it to match.
- toNot - Expect it to not match.
- beTruthy() - That it's true
- beFalsy()
- beCloseTo(expectedValue, within: Double = 0.0001)
- beLessThan(upperLimit)
- beGreaterThan(upperLimit)
- be(Less|Greater)ThanOrEqualTo(lowerLimit)
writing more tests
writing more tests
writing more tests
Writing more tests
Writing more tests
why and which paradigm would this method be a bad practice in?
implementing withdrawal
What is describe?
Describe allows us to wrap a set of tests against one bit of functionality.
In our case, our method #withdrawal.
We use # to indicate an instance methods name.
We use . when indicating a class methods name.
This is a style from Ruby/RSpec best practices.
implementing withdrawal
implementing withdrawal
what happens if we overdraw?
implementing the overdraft fee
WHAT IS CONTEXT?
We use context to specify conditional behavior
with positive balance.
with negative balance.
implementing the overdraft fee
because we have tests and we are awesome developers we can?
refactor!
Move the fee applying functionality to it's own method.
This allows us to give this bit of functionality a name.
refactoring our tests
refactoring our tests
Text
We can share setup code with beforeEach
There's also afterEach (runs after each test), afterSuite, and beforeSuite.
That's it for now
Follow @adamjleonard
http://www.adamjleonard.com
Subscribe to
http://www.swifcast.tv
Add Swift libraries to
http://www.swifttoolbox.io
Check out the company I work for!
http://www.happyfuncorp.com