Testing

  • 31 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
31
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
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