Test-Driven Development with Python

Book description

By taking you through the development of a real web application from beginning to end, this hands-on guide demonstrates the practical advantages of test-driven development (TDD) with Python. You’ll learn the basics of Django, Selenium, Git, jQuery, and Mock, along with current web development techniques.

Publisher resources

View/Submit Errata

Table of contents

  1. Praise for Test-Driven Development with Python
  2. Preface
    1. Why I Wrote a Book About Test-Driven Development
    2. Aims of This Book
    3. Outline
    4. Conventions Used in This Book
    5. Using Code Examples
    6. Safari® Books Online
    7. Contacting O’Reilly
  3. Prerequisites and Assumptions
    1. Python 3 and Programming
    2. How HTML Works
    3. JavaScript
    4. Required Software Installations
      1. Git’s Default Editor, and Other Basic Git Config
      2. Required Python Packages
  4. Acknowledgments
  5. I. The Basics of TDD and Django
    1. 1. Getting Django Set Up Using a Functional Test
      1. Obey the Testing Goat! Do Nothing Until You Have a Test
      2. Getting Django Up and Running
      3. Starting a Git Repository
    2. 2. Extending Our Functional Test Using the unittest Module
      1. Using a Functional Test to Scope Out a Minimum Viable App
      2. The Python Standard Library’s unittest Module
      3. Implicit waits
      4. Commit
    3. 3. Testing a Simple Home Page with Unit Tests
      1. Our First Django App, and Our First Unit Test
      2. Unit Tests, and How They Differ from Functional Tests
      3. Unit Testing in Django
      4. Django’s MVC, URLs, and View Functions
      5. At Last! We Actually Write Some Application Code!
      6. urls.py
      7. Unit Testing a View
        1. The Unit-Test/Code Cycle
    4. 4. What Are We Doing with All These Tests?
      1. Programming Is like Pulling a Bucket of Water up from a Well
      2. Using Selenium to Test User Interactions
      3. The “Don’t Test Constants” Rule, and Templates to the Rescue
        1. Refactoring to Use a Template
      4. On Refactoring
      5. A Little More of Our Front Page
      6. Recap: The TDD Process
    5. 5. Saving User Input
      1. Wiring Up Our Form to Send a POST Request
      2. Processing a POST Request on the Server
      3. Passing Python Variables to Be Rendered in the Template
      4. Three Strikes and Refactor
      5. The Django ORM and Our First Model
        1. Our First Database Migration
        2. The Test Gets Surprisingly Far
        3. A New Field Means a New Migration
      6. Saving the POST to the Database
      7. Redirect After a POST
        1. Better Unit Testing Practice: Each Test Should Test One Thing
      8. Rendering Items in the Template
      9. Creating Our Production Database with migrate
    6. 6. Getting to the Minimum Viable Site
      1. Ensuring Test Isolation in Functional Tests
        1. Running Just the Unit Tests
      2. Small Design When Necessary
        1. YAGNI!
        2. REST
      3. Implementing the New Design Using TDD
      4. Iterating Towards the New Design
      5. Testing Views, Templates, and URLs Together with the Django Test Client
        1. A New Test Class
        2. A New URL
        3. A New View Function
          1. Green? Refactor
        4. A Separate Template for Viewing Lists
      6. Another URL and View for Adding List Items
        1. A Test Class for New List Creation
        2. A URL and View for New List Creation
        3. Removing Now-Redundant Code and Tests
        4. Pointing Our Forms at the New URL
      7. Adjusting Our Models
        1. A Foreign Key Relationship
        2. Adjusting the Rest of the World to Our New Models
      8. Each List Should Have Its Own URL
        1. Capturing Parameters from URLs
        2. Adjusting new_list to the New World
      9. One More View to Handle Adding Items to an Existing List
        1. Beware of Greedy Regular Expressions!
        2. The Last New URL
        3. The Last New View
        4. But How to Use That URL in the Form?
      10. A Final Refactor Using URL includes
  6. II. Web Development Sine Qua Nons
    1. 7. Prettification: Layout and Styling, and What to Test About It
      1. What to Functionally Test About Layout and Style
      2. Prettification: Using a CSS Framework
      3. Django Template Inheritance
      4. Integrating Bootstrap
        1. Rows and Columns
      5. Static Files in Django
        1. Switching to StaticLiveServerTestCase
      6. Using Bootstrap Components to Improve the Look of the Site
        1. Jumbotron!
        2. Large Inputs
        3. Table Styling
      7. Using Our Own CSS
      8. What We Glossed Over: collectstatic and Other Static Directories
      9. A Few Things That Didn’t Make It
    2. 8. Testing Deployment Using a Staging Site
      1. TDD and the Danger Areas of Deployment
      2. As Always, Start with a Test
      3. Getting a Domain Name
      4. Manually Provisioning a Server to Host Our Site
        1. Choosing Where to Host Our Site
        2. Spinning Up a Server
        3. User Accounts, SSH, and Privileges
        4. Installing Nginx
        5. Configuring Domains for Staging and Live
        6. Using the FT to Confirm the Domain Works and Nginx Is Running
      5. Deploying Our Code Manually
        1. Adjusting the Database Location
        2. Creating a Virtualenv
        3. Simple Nginx Configuration
        4. Creating the Database with migrate
      6. Getting to a Production-Ready Deployment
        1. Switching to Gunicorn
        2. Getting Nginx to Serve Static Files
        3. Switching to Using Unix Sockets
        4. Switching DEBUG to False and Setting ALLOWED_HOSTS
        5. Using Upstart to Make Sure Gunicorn Starts on Boot
        6. Saving Our Changes: Adding Gunicorn to Our requirements.txt
      7. Automating
        1. “Saving Your Progress”
    3. 9. Automating Deployment with Fabric
      1. Breakdown of a Fabric Script for Our Deployment
      2. Trying It Out
        1. Deploying to Live
        2. Nginx and Gunicorn Config Using sed
      3. Git Tag the Release
      4. Further Reading
    4. 10. Input Validation and Test Organisation
      1. Validation FT: Preventing Blank Items
        1. Skipping a Test
        2. Splitting Functional Tests out into Many Files
        3. Running a Single Test File
        4. Fleshing Out the FT
      2. Using Model-Layer Validation
        1. Refactoring Unit Tests into Several Files
        2. Unit Testing Model Validation and the self.assertRaises Context Manager
        3. A Django Quirk: Model Save Doesn’t Run Validation
      3. Surfacing Model Validation Errors in the View
        1. Checking Invalid Input Isn’t Saved to the Database
      4. Django Pattern: Processing POST Requests in the Same View as Renders the Form
        1. Refactor: Transferring the new_item Functionality into view_list
        2. Enforcing Model Validation in view_list
      5. Refactor: Removing Hardcoded URLs
        1. The {% url %} Template Tag
        2. Using get_absolute_url for Redirects
    5. 11. A Simple Form
      1. Moving Validation Logic into a Form
        1. Exploring the Forms API with a Unit Test
        2. Switching to a Django ModelForm
        3. Testing and Customising Form Validation
      2. Using the Form in Our Views
        1. Using the Form in a View with a GET Request
        2. A Big Find and Replace
      3. Using the Form in a View That Takes POST Requests
        1. Adapting the Unit Tests for the new_list View
        2. Using the Form in the View
        3. Using the Form to Display Errors in the Template
      4. Using the Form in the Other View
        1. A Helper Method for Several Short Tests
      5. Using the Form’s Own Save Method
    6. 12. More Advanced Forms
      1. Another FT for Duplicate Items
        1. Preventing Duplicates at the Model Layer
        2. A Little Digression on Queryset Ordering and String Representations
        3. Rewriting the Old Model Test
        4. Some Integrity Errors Do Show Up on Save
      2. Experimenting with Duplicate Item Validation at the Views Layer
      3. A More Complex Form to Handle Uniqueness Validation
      4. Using the Existing List Item Form in the List View
    7. 13. Dipping Our Toes, Very Tentatively, into JavaScript
      1. Starting with an FT
      2. Setting Up a Basic JavaScript Test Runner
      3. Using jQuery and the Fixtures Div
      4. Building a JavaScript Unit Test for Our Desired Functionality
      5. Javascript Testing in the TDD Cycle
      6. Columbo Says: Onload Boilerplate and Namespacing
      7. A Few Things That Didn’t Make It
    8. 14. Deploying Our New Code
      1. Staging Deploy
      2. Live Deploy
      3. What to Do If You See a Database Error
      4. Wrap-Up: git tag the New Release
  7. III. More Advanced Topics
    1. 15. User Authentication, Integrating Third-Party Plugins, and Mocking with JavaScript
      1. Mozilla Persona (BrowserID)
      2. Exploratory Coding, aka “Spiking”
        1. Starting a Branch for the Spike
        2. Frontend and JavaScript Code
        3. The Browser-ID Protocol
        4. The Server Side: Custom Authentication
      3. De-spiking
        1. A Common Selenium Technique: Explicit Waits
        2. Reverting Our Spiked Code
      4. JavaScript Unit Tests Involving External Components: Our First Mocks!
        1. Housekeeping: A Site-Wide Static Files Folder
        2. Mocking: Who, Why, What?
        3. Namespacing
        4. A Simple Mock to Unit Tests Our initialize Function
        5. More Advanced Mocking
          1. Using a sinon.js mock to check we call the API correctly
        6. Checking Call Arguments
        7. QUnit setup and teardown, Testing Ajax
          1. Logout
        8. More Nested Callbacks! Testing Asynchronous Code
    2. 16. Server-Side Authentication and Mocking in Python
      1. A Look at Our Spiked Login View
      2. Mocking in Python
        1. Testing Our View by Mocking Out authenticate
        2. Checking the View Actually Logs the User In
      3. De-spiking Our Custom Authentication Backend: Mocking Out an Internet Request
        1. 1 if = 1 More Test
        2. Patching at the Class Level
        3. Beware of Mocks in Boolean Comparisons
        4. Creating a User if Necessary
        5. The get_user Method
      4. A Minimal Custom User Model
        1. A Slight Disappointment
        2. Tests as Documentation
        3. Users Are Authenticated
      5. The Moment of Truth: Will the FT Pass?
      6. Finishing Off Our FT, Testing Logout
    3. 17. Test Fixtures, Logging, and Server-Side Debugging
      1. Skipping the Login Process by Pre-creating a Session
        1. Checking It Works
      2. The Proof Is in the Pudding: Using Staging to Catch Final Bugs
        1. Setting Up Logging
        2. Fixing the Persona Bug
      3. Managing the Test Database on Staging
        1. A Django Management Command to Create Sessions
        2. Getting the FT to Run the Management Command on the Server
        3. An Additional Hop via subprocess
      4. Baking In Our Logging Code
        1. Using Hierarchical Logging Config
      5. Wrap-Up
    4. 18. Finishing “My Lists”: Outside-In TDD
      1. The Alternative: “Inside Out”
      2. Why Prefer “Outside-In”?
      3. The FT for “My Lists”
      4. The Outside Layer: Presentation and Templates
      5. Moving Down One Layer to View Functions (the Controller)
      6. Another Pass, Outside-In
        1. A Quick Restructure of the Template Inheritance Hierarchy
        2. Designing Our API Using the Template
        3. Moving Down to the Next Layer: What the View Passes to the Template
      7. The Next “Requirement” from the Views Layer: New Lists Should Record Owner
        1. A Decision Point: Whether to Proceed to the Next Layer with a Failing Test
      8. Moving Down to the Model Layer
        1. Final Step: Feeding Through the .name API from the Template
    5. 19. Test Isolation, and “Listening to Your Tests”
      1. Revisiting Our Decision Point: The Views Layer Depends on Unwritten Models Code
      2. A First Attempt at Using Mocks for Isolation
        1. Using Mock side_effects to Check the Sequence of Events
      3. Listen to Your Tests: Ugly Tests Signal a Need to Refactor
      4. Rewriting Our Tests for the View to Be Fully Isolated
        1. Keep the Old Integrated Test Suite Around as a Sanity Check
        2. A New Test Suite with Full Isolation
        3. Thinking in Terms of Collaborators
      5. Moving Down to the Forms Layer
        1. Keep Listening to Your Tests: Removing ORM Code from Our Application
      6. Finally, Moving Down to the Models Layer
        1. Back to Views
      7. The Moment of Truth (and the Risks of Mocking)
      8. Thinking of Interactions Between Layers as “Contracts”
        1. Identifying Implicit Contracts
        2. Fixing the Oversight
      9. One More Test
      10. Tidy Up: What to Keep from Our Integrated Test Suite
        1. Removing Redundant Code at the Forms Layer
        2. Removing the Old Implementation of the View
        3. Removing Redundant Code at the Forms Layer
      11. Conclusions: When to Write Isolated Versus Integrated Tests
        1. Let Complexity Be Your Guide
        2. Should You Do Both?
        3. Onwards!
    6. 20. Continuous Integration (CI)
      1. Installing Jenkins
        1. Configuring Jenkins Security
        2. Adding Required Plugins
          1. Telling Jenkins where to find Python 3 and Xvfb
      2. Setting Up Our Project
      3. First Build!
      4. Setting Up a Virtual Display so the FTs Can Run Headless
      5. Taking Screenshots
      6. A Common Selenium Problem: Race Conditions
      7. Running Our QUnit JavaScript Tests in Jenkins with PhantomJS
        1. Installing node
        2. Adding the Build Steps to Jenkins
      8. More Things to Do with a CI Server
    7. 21. The Token Social Bit, the Page Pattern, and an Exercise for the Reader
      1. An FT with Multiple Users, and addCleanup
      2. Implementing the Selenium Interact/Wait Pattern
      3. The Page Pattern
      4. Extend the FT to a Second User, and the “My Lists” Page
      5. An Exercise for the Reader
    8. 22. Fast Tests, Slow Tests, and Hot Lava
      1. Thesis: Unit Tests Are Superfast and Good Besides That
        1. Faster Tests Mean Faster Development
        2. The Holy Flow State
        3. Slow Tests Don’t Get Run as Often, Which Causes Bad Code
        4. We’re Fine Now, but Integrated Tests Get Slower Over Time
        5. Don’t Take It from Me
        6. And Unit Tests Drive Good Design
      2. The Problems with “Pure” Unit Tests
        1. Isolated Tests Can Be Harder to Read and Write
        2. Isolated Tests Don’t Automatically Test Integration
        3. Unit Tests Seldom Catch Unexpected Bugs
        4. Mocky Tests Can Become Closely Tied to Implementation
        5. But All These Problems Can Be Overcome
      3. Synthesis: What Do We Want from Our Tests, Anyway?
        1. Correctness
        2. Clean, Maintainable Code
        3. Productive Workflow
        4. Evaluate Your Tests Against the Benefits You Want from Them
      4. Architectural Solutions
        1. Ports and Adapters/Hexagonal/Clean Architecture
        2. Functional Core, Imperative Shell
      5. Conclusion
    9. Obey the Testing Goat!
      1. Testing Is Hard
        1. Keep Your CI Builds Green
        2. Take Pride in Your Tests, as You Do in Your Code
      2. Remember to Tip the Bar Staff
      3. Don’t Be a Stranger!
    10. A. PythonAnywhere
      1. Running Firefox Selenium Sessions with Xvfb
      2. Setting Up Django as a PythonAnywhere Web App
      3. Cleaning Up /tmp
      4. Screenshots
      5. The Deployment Chapter
    11. B. Django Class-Based Views
      1. Class-Based Generic Views
      2. The Home Page as a FormView
      3. Using form_valid to Customise a CreateView
      4. A More Complex View to Handle Both Viewing and Adding to a List
        1. The Tests Guide Us, for a While
        2. Until We’re Left with Trial and Error
        3. Back on Track
        4. Is That Your Final Answer?
      5. Compare Old and New
      6. Best Practices for Unit Testing CBGVs?
        1. Take-Home: Having Multiple, Isolated View Tests with Single Assertions Helps
    12. C. Provisioning with Ansible
      1. Installing System Packages and Nginx
      2. Configuring Gunicorn, and Using Handlers to Restart Services
      3. What to Do Next
        1. Move Deployment out of Fabric and into Ansible
        2. Use Vagrant to Spin Up a Local VM
    13. D. Testing Database Migrations
      1. An Attempted Deploy to Staging
      2. Running a Test Migration Locally
        1. Entering Problematic Data
        2. Copying Test Data from the Live Site
        3. Confirming the Error
      3. Inserting a Data Migration
        1. Re-creating the Old Migration
      4. Testing the New Migrations Together
      5. Conclusions
    14. E. What to Do Next
      1. Notifications—Both on the Site and by Email
      2. Switch to Postgres
      3. Run Your Tests Against Different Browsers
      4. 404 and 500 Tests
      5. The Django Admin Site
      6. Investigate a BDD Tool
      7. Write Some Security Tests
      8. Test for Graceful Degradation
      9. Caching and Performance Testing
      10. JavaScript MVC Frameworks
      11. Async and Websockets
      12. Switch to Using py.test
      13. Client-Side Encryption
      14. Your Suggestion Here
    15. F. Cheat Sheet
      1. Initial Project Setup
      2. The Basic TDD Workflow
      3. Moving Beyond dev-only Testing
      4. General Testing Best Practices
      5. Selenium/Functional Testing Best Practices
      6. Outside-In, Test Isolation Versus Integrated Tests, and Mocking
    16. G. Bibliography
  8. Index
  9. Colophon
  10. Copyright

Product information

  • Title: Test-Driven Development with Python
  • Author(s):
  • Release date: June 2014
  • Publisher(s): O'Reilly Media, Inc.
  • ISBN: 9781449364823