Your SlideShare is downloading. ×
Testing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Testing

39
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
39
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Result – inputs -> outputs
    Side Effects – Car model -> start engine -> update boolean engine running
    Speedy – app needing 1000 calls per second
    Tests prior – instead of throwing together tests at the end – plan ahead
  • Regression – knowing previous code won’t brake
    Design – break up code into small pieces
    Done coding – good design == confidence
  • Unit – small units – possibly mocking out external dependencies
    Integration – testing units with their dependencies to make sure interactions work
    System – Calling only public API endpoints/functions and using the full stack
    Acceptance – automated based on user stories – could be written by someone other than developer - or just manual user testing
  • BaseTestCase - built on top of unittest
  • Generally would have API calls for a system running on a staging environment, but this I hope still shows the difference
  • Transcript

    • 1. Testing Will Weaver
    • 2. What I Mean by Testing? • Automatic and repeatable checking that code written works as expected. • • Correct side effects • • Correct result Speedy enough Writing tests prior to writing code
    • 3. Why Test? • Reduce regression bugs • Increase code quality • • • Better design Find problems early Helps you know when you are done coding
    • 4. Levels of Testing • Unit • Integration • System / End-to-End • Acceptance
    • 5. Unit Testing • Testing small units • Test all cases / scenarios • Mock / Patch external calls
    • 6. Unit Test Example 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # transaction.py class Transaction(object): def __init__(self, action, amount): self.action = action self.amount = amount # bank_account.py class BankAccount(object): def __init__(self, initial_balance=0): self.balance = initial_balance self.transactions = [Transaction('initial', initial_balance)]
    • 7. Unit Test Example (cont'd) 17 # test_bank_account.py 18 class DescribeBankAccount(BaseTestCase): 19 20 # Arrange 21 @classmethod 22 def configure(cls): 23 cls.init_balance = 10.0 24 cls.transaction = cls.create_patch('bank_account.Transaction') 25 26 # Act 27 @classmethod 28 def execute(cls): 29 cls.bank_account = BankAccount(cls.init_balance) 30 31 # Assert 32 def should_have_balance(self): 33 self.assertEqual(self.bank_account.balance, self.init_balance) 34 35 def should_create_transaction(self): 36 self.transaction.assert_called_once_with('initial', self.init_balance) 37 38 def should_have_transactions(self): 39 self.assertEqual( 40 self.bank_account.transactions, [self.transaction.return_value])
    • 8. Integration Testing • Test interaction with dependencies / external calls • Not as detailed as unit tests - no need to test every scenario • Minimal mocking / patching
    • 9. Integration Test Example 17 # test_bank_account.py 18 class DescribeBankAccount(BaseTestCase): 19 20 # Arrange 21 @classmethod 22 def configure(cls): 23 cls.init_balance = 10.0 24 25 # Act 26 @classmethod 27 def execute(cls): 28 cls.bank_account = BankAccount(cls.init_balance) 29 30 # Assert 31 def should_have_transactions(self): 32 self.assertEqual( 33 self.bank_account.transactions, 34 [Transaction('initial', self.init_balance)], 35 )
    • 10. System / End-to-End Testing • Test public endpoints • Use full stack • No mocking / patching • Minimal to no inspecting of underlying side effects - only results of calls • Run in a staging environment
    • 11. System Test Example 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 # transaction.py class Transaction(object): def __init__(self, action, amount): self.action = action self.amount = amount # bank_account.py class BankAccount(object): def __init__(self, initial_balance=0): self._balance = initial_balance self._transactions = [Transaction('initial', initial_balance)] def deposit(self, amount): self._balance += amount self._transactions.append(Transaction('deposit', amount)) def withdraw(self, amount): self._balance -= amount self._transactions.append(Transaction('withdrawal', amount)) def get_transactions(self): return self._transactions
    • 12. System Test Example (cont’d) 28 # test_bank_account.py 29 class WhenDepositingToBankAccount(BaseTestCase): 30 31 # Arrange 32 @classmethod 33 def configure(cls): 34 cls.bank_account = BankAccount(100.0) 35 36 # Act 37 @classmethod 38 def execute(cls): 39 cls.bank_account.deposit(20.0) 40 cls.bank_account.deposit(25.0) 41 cls.bank_account.withdrawal(10.0) 42 cls.bank_account.withdrawal(5.0) 43 cls.transactions = cls.bank_account.get_transactions() 44 45 # Assert 46 def should_have_transactions(self): 47 self.assertEqual(len(self.transactions), 5)
    • 13. Acceptance Testing • Fulfill user stories • Can be written and/or manual • Could be written by someone other than developer - stakeholder • Full stack • Run against staging environment
    • 14. Acceptance Testing Frameworks • https://pypi.python.org/pypi/behave • http://robotframework.org/ • A few more found here: https://wiki.python.org/moin/PythonTestingToolsT axonomy#Acceptance.2FBusiness_Logic_Testin g_Tools