Test-Driven Development with Python. Obey the Testing Goat: Using Django, Selenium, and JavaScript. 3rd Edition Harry Percival

Dostępność produktu

Produkt nie został jeszcze oceniony pod kątem ułatwień dostępu lub nie podano żadnych informacji o ułatwieniach dostępu lub są one niewystarczające. Prawdopodobnie Wydawca/Dostawca jeszcze nie umożliwił dokonania walidacji produktu lub nie przekazał odpowiednich informacji na temat jego dostępności.

Spis treści książki

• Preface
  • Why I Wrote a Book About Test-Driven Development
  • Aims of This Book
  • Outline
  • Conventions Used in This Book
  • Submitting Errata
  • Using Code Examples
  • OReilly Online Learning
  • How to Contact Us
  • Companion Video
  • License for the Free Edition
• Preface to the Third Edition: TDD in the Age of AI
  • AI Is Both Insanely Impressive and Incredibly Unreliable
  • Mitigations for AIs Shortcomings Sure Look a Lot Like TDD
  • Leaky Abstractions and the Importance of Experience
    • My Own Experiences with AI
  • The AI-Enabled Workflow of the Future
• Prerequisites and Assumptions
  • Python 3 and Programming
  • How HTML Works
  • Django
  • JavaScript
  • Required Software Installations
    • Installing Firefox
  • Setting Up Your Virtualenv
    • Activating and Deactivating the Virtualenv
    • Installing Django and Selenium
    • Some Error Messages Youre Likely to See When You Inevitably Fail to Activate Your Virtualenv
• Acknowledgments
  • Additional Thanks for the Second Edition
  • Additional Thanks for the Third Edition
• I. The Basics of TDD and Django
• 1. Getting Django Set Up Using a Functional Test
  • Obey the Testing Goat! Do Nothing Until You Have a Test
  • Getting Django Up and Running
  • Starting a Git Repository
• 2. Extending Our Functional Test Using the unittest Module
  • Using a Functional Test to Scope Out a Minimum Viable App
  • The Python Standard Librarys unittest Module
  • Commit
• 3. Testing a Simple Home Page with Unit Tests
  • Our First Django App and Our First Unit Test
  • Unit Tests, and How They Differ from Functional Tests
  • Unit Testing in Django
  • Djangos MVC, URLs, and View Functions
  • Unit Testing a View
    • At Last! We Actually Write Some Application Code!
    • The Unit-Test/Code Cycle
  • Our Functional Tests Tell Us Were Not Quite Done Yet
  • Reading Tracebacks
  • urls.py
• 4. What Are We Doing with All These Tests? (And, Refactoring)
  • Programming Is Like Pulling a Bucket of Water Up from a Well
  • Using Selenium to Test User Interactions
  • The Dont Test Constants Rule, and Templates to the Rescue
    • Refactoring to Use a Template
  • Revisiting Our Unit Tests
    • Test Behaviour, Not Implementation
  • On Refactoring
  • A Little More of Our Front Page
  • Recap: The TDD Process
    • Double-Loop TDD
• 5. Saving User Input: Testing the Database
  • Wiring Up Our Form to Send a POST Request
  • Testing the Contract Between Frontend and Backend
  • Debugging Functional Tests
    • Debugging with time.sleep
  • Processing a POST Request on the Server
  • Passing Python Variables to Be Rendered in the Template
    • An Unexpected Failure
    • Improving Error Messages in Tests
  • Three Strikes and Refactor
  • The Django ORM and Our First Model
    • Our First Database Migration
    • The Test Gets Surprisingly Far
    • A New Field Means a New Migration
  • Saving the POST to the Database
  • Redirect After a POST
  • Better Unit Testing Practice: Each Test Should Test One Thing
  • Rendering Items in the Template
  • Creating Our Production Database with migrate
  • Recap
• 6. Improving Functional Tests: Ensuring Isolation and Removing Magic Sleeps
  • Ensuring Test Isolation in Functional Tests
    • Running Just the Unit Tests
  • On Implicit and Explicit Waits, and Magic time.sleeps
• 7. Working Incrementally
  • Small Design When Necessary
    • Not Big Design Up Front
    • YAGNI!
    • REST-ish
  • Implementing the New Design Incrementally Using TDD
  • Ensuring We Have a Regression Test
  • Iterating Towards the New Design
  • Taking a First, Self-Contained Step: One New URL
    • Separating Out Our Home Page and List View Functionality
      • A new view function
    • The FTs Detect a Regression
    • Getting Back to a Working State as Quickly as Possible
    • Green? Refactor
  • Another Small Step: A Separate Template for Viewing Lists
  • A Third Small Step: A New URL for Adding List Items
    • A Test Class for New List Creation
    • A URL and View for New List Creation
    • Removing Now-Redundant Code and Tests
    • A Regression! Pointing Our Forms at the New URL
    • Debugging in DevTools
  • Biting the Bullet: Adjusting Our Models
    • A Foreign Key Relationship
    • Adjusting the Rest of the World to Our New Models
  • Each List Should Have Its Own URL
    • Capturing Parameters from URLs
    • Adjusting new_list to the New World
  • The Functional Tests Detect Another Regression
  • One More URL to Handle Adding Items to an Existing List
    • The Last New urls.py Entry
    • The Last New View
    • Testing Template Context Directly
  • A Final Refactor Using URL includes
    • Can You Believe It?
• 8. Prettification: Layout and Styling, and What to Test About It
  • Testing Layout and Style
  • Prettification: Using a CSS Framework
  • Django Template Inheritance
  • Integrating Bootstrap
    • Rows and Columns
  • Static Files in Django
    • Switching to StaticLiveServerTestCase
  • Using Bootstrap Components to Improve the Look of the Site
    • Jumbotron!
    • Large Inputs
    • Table Styling
    • Optional: Dark Mode
    • A Semi-Decent Page
  • Parsing HTML for Less Brittle Tests of Key HTML Content
  • What We Glossed Over: collectstatic and Other Static Directories
  • A Few Things That Didnt Make It
• II. Going to Production
• 9. Containerization aka Docker
  • Docker, Containers, and Virtualization
    • Why Not Just Use a Virtualenv?
    • Docker and Your CV
  • As Always, Start with a Test
    • Making a src Folder
  • Installing Docker
  • Building a Docker Image and Running a Docker Container
    • A First Cut of a Dockerfile
    • Docker Build
    • Docker Run
  • Installing Django in a Virtualenv in Our Container Image
    • Successful Run
  • Using the FT to Check That Our Container Works
  • Debugging Container Networking Problems
    • Debugging Web Server Connectivity with curl
  • Running Code Inside the Container with docker exec
    • Docker Port Mapping
    • Essential Googling the Error Message
  • Database Migrations
    • Should We Run migrate Inside the Dockerfile? No.
  • Mounting Files Inside the Container
• 10. Making Our App Production-Ready
  • What We Need to Do
  • Switching to Gunicorn
    • The FTs Catch a Problem with Static Files
  • Serving Static Files with WhiteNoise
  • Using requirements.txt
  • Using Environment Variables to Adjust Settings for Production
    • Setting DEBUG=True and SECRET_KEY
    • Setting Environment Variables Inside the Dockerfile
    • Setting Environment Variables at the Docker Command Line
    • ALLOWED_HOSTS Is Required When Debug Mode Is Turned Off
    • Collectstatic Is Required when Debug Is Turned Off
  • Switching to a Nonroot User
    • Making the Database Filepath Configurable
    • Using UIDs to Set Permissions Across Host/Container Mounts
  • Configuring Logging
    • Provoking a Deliberate Error
  • Exercise for the Reader: Using the Django check Command
  • Wrap-Up
• 11. Getting a Server Ready for Deployment
  • Manually Provisioning a Server to Host Our Site
    • Choosing Where to Host Our Site
    • Spinning Up Our Own Server
  • Getting a Domain Name
  • Configuring DNS for Staging and Live Domains
  • Ansible
    • Ansible Versus SSH: How Well Talk to Our Server
  • Start by Making Sure We Can SSH In
    • Debugging Issues with SSH
      • Debugging network connectivity
      • Debugging SSH auth issues
    • Installing Ansible
    • Checking Ansible Can Talk to Our Server
• 12. Infrastructure as Code: Automated Deployments with Ansible
  • A First Cut of an Ansible Playbook for Deployment
  • SSHing Into the Server and Viewing Container Logs
  • Allowing Rootless Docker Access
  • Getting Our Image Onto the Server
    • Taking a Look Around Manually
      • Docker logs
  • Setting Environment Variables and Secrets
    • Manually Checking Environment Variables for Running Containers
      • docker exec env
      • docker inspect
  • Running FTs to Check on Our Deploy
    • Manual Debugging with curl Against the Staging Server
  • Mounting the Database on the Server and Running Migrations
  • It Workssss
  • Deploying to Prod
  • git tag the Release
  • Tell Everyone!
  • Further Reading
• III. Forms and Validation
• 13. Splitting Our Tests into Multiple Files, and a Generic Wait Helper
  • Start on a Validation FT: Preventing Blank Items
    • Skipping a Test
  • Splitting Functional Tests Out into Many Files
  • Running a Single Test File
  • A New FT Tool: A Generic Explicit Wait Helper
  • Finishing Off the FT
  • Refactoring Unit Tests into Several Files
• 14. Validation at the Database Layer
  • Model-Layer Validation
    • The self.assertRaises Context Manager
    • Django Model Constraints and Their Interaction with Databases
    • Inspecting Our Constraints at the Database Level
    • Testing Django Model Validation
    • A Django Quirk: Model Save Doesnt Run Validation
  • Surfacing Model Validation Errors in the View
    • Checking That Invalid Input Isnt Saved to the Database
    • Adding an Early Return to Our FT to Let Us Refactor Against Green
  • Django Pattern: Processing POST Requests in the Same View That Renders the Form
    • Refactor: Transferring the new_item Functionality into view_list
    • Enforcing Model Validation in view_list
  • Refactor: Removing Hardcoded URLs
    • The {% url %} Template Tag
    • Using get_absolute_url for Redirects
• 15. A Simple Form
  • Moving Validation Logic Into a Form
    • Exploring the Forms API with a Unit Test
    • Switching to a Django ModelForm
    • Testing and Customising Form Validation
  • Attempting to Use the Form in Our Views
    • Using the Form in a View with a GET Request
    • The Trade-offs of Django ModelForms: The Frontend Is Coupled to the Database
  • A Big Find-and-Replace
    • Backing Out Our Changes and Getting to a Working State
    • Renaming the name Attribute
    • Renaming the id Attribute
  • A Second Attempt at Using the Form in Our Views
  • Using the Form in a View That Takes POST Requests
    • Using the Form to Display Errors in the Template
    • Get Back to a Working State
    • A Helper Method for Several Short Tests
  • Using the Form in the Existing Lists View
    • Using the Form to Pass Errors to the Template
    • Refactoring the View to Use the Form Fully
  • An Unexpected Benefit: Free Client-Side Validation from HTML5
  • A Pat on the Back
    • But Have We Wasted a Lot of Time?
  • Using the ModelForms Own Save Method
• 16. More Advanced Forms
  • Another FT for Duplicate Items
    • Preventing Duplicates at the Model Layer
    • Rewriting the Old Model Test
    • Integrity Errors That Show Up on Save
  • Experimenting with Duplicate Item Validation at the Views Layer
  • A More Complex Form to Handle Uniqueness Validation
  • Using the Existing List Item Form in the List View
    • Customising the Save Method on Our New Form
  • The FTs Pick Up an Issue with Bootstrap Classes
  • Conditionally Customising CSS Classes for Invalid Forms
    • A Little Digression on Queryset Ordering and String Representations
  • On the Trade-offs of Django ModelForms, and Frameworks in General
    • Moving Presentation Logic Back into the Template
    • Tidying Up the Forms
    • Switching Back to Simple Forms
  • Wrapping Up: What Weve Learned About Testing Django
• IV. More Advanced Topics in Testing
• 17. A Gentle Excursion into JavaScript
  • Starting with an FT
  • A Quick Spike
    • A Simple Inline Script
    • Using the Browser DevTools
  • Choosing a Basic JavaScript Test Runner
  • An Overview of Jasmine
  • Setting Up Our JavaScript Test Environment
  • Our First Smoke Test: Describe, It, Expect
    • Running the Tests via the Browser
  • Testing with Some DOM Content
  • Building a JavaScript Unit Test for Our Desired Functionality
  • Fixtures, Execution Order, and Global State: Key Challenges of JavaScript Testing
    • console.log for Debug Printing
  • Using an Initialize Function for More Control Over Execution Time
  • Deliberately Breaking Our Code to Force Ourselves to Write More Tests
  • Red/Green/Refactor: Removing Hardcoded Selectors
  • Does it Work?
  • Testing Integration with CSS and Bootstrap
  • Columbo Says: Wait for Onload
  • JavaScript Testing in the TDD Cycle
• 18. Deploying Our New Code
  • The Deployment Checklist
  • A Full Test Run Locally
  • Quick Test Run Against Docker
  • Staging Deploy and Test Run
  • Production Deploy
  • What to Do If You See a Database Error
    • How to Delete the Database on the Staging Server
  • Wrap-Up: git tag the New Release
• 19. User Authentication, Spiking, and De-Spiking
  • Passwordless Auth with Magic Links
  • A Somewhat Larger Spike
    • Starting a Branch for the Spike
    • Frontend Login UI
    • Sending Emails from Django
    • Email Server Config for Django
    • Another Secret, Another Environment Variable
    • Storing Tokens in the Database
    • Custom Authentication Models
    • Finishing the Custom Django Auth
  • De-Spiking
    • Making a Plan
    • Wring an FT Against the Spiked Code
    • Reverting Our Spiked Code
  • A Minimal Custom User Model
    • Tests as Documentation
  • A Token Model to Link Emails with a Unique ID
• 20. Using Mocks to Test External Dependencies
  • Before We Start: Getting the Basic Plumbing In
  • Mocking Manuallyaka Monkeypatching
  • The Python Mock Library
    • Using unittest.patch
    • Getting the FT a Little Further Along
    • Testing the Django Messages Framework
    • Adding Messages to Our HTML
    • Starting on the Login URL
    • Checking That We Send the User a Link with a Token
  • De-Spiking Our Custom Authentication Backend
    • One if = One More Test
    • The get_user Method
• 21. Using Mocks for Test Isolation
  • Using Our Auth Backend in the Login View
    • Straightforward Non-Mocky Test for Our View
  • Combinatorial Explosion
    • The Car Factory Example
  • Using Mocks to Test Parts of Our System in Isolation
    • Mocks Can Also Let You Test the Implementation, When It Matters
  • Starting Again: Test-Driving Our Implementation with Mocks
    • Using mock.return_value
    • Using .return_value During Test Setup
    • UnDONTifying
  • Deciding Which Tests to Keep
  • The Moment of Truth: Will the FT Pass?
  • It Works in Theory! Does It Work in Practice?
    • Using Our New Environment Variable, and Saving It to .env
  • Finishing Off Our FT: Testing Logout
• 22. Test Fixtures and a Decorator for Explicit Waits
  • Skipping the Login Process by Pre-creating a Session
    • Checking That It Works
  • Our Final Explicit Wait Helper: A Wait Decorator
• 23. Debugging and Testing Server Issues
  • The Proof Is in the Pudding: Using Docker to Catch Final Bugs
  • Inspecting the Docker Container Logs
  • Another Environment Variable in Docker
    • mail.outbox Wont Work Outside Djangos Test Environment
  • Deciding How to Test Real Email Sending
  • An Alternative Method for Setting Secret Environment Variables on the Server
  • Debugging with SQL
  • Managing Fixtures in Real Databases
    • A Django Management Command to Create Sessions
    • Getting the FT to Run the Management Command on the Server
    • Running Commands Using Docker Exec and (Optionally) SSH
    • Recap: Creating Sessions Locally Versus Staging
      • Locally:
      • Against Docker locally:
      • Against Docker on the server:
  • Testing the Management Command
  • Test Database Cleanup
  • Wrap-Up
• 24. Finishing My Lists: Outside-In TDD
  • The Alternative: Inside-Out
  • Why Prefer Outside-In?
  • The FT for My Lists
  • The Outside Layer: Presentation and Templates
  • Moving Down One Layer to View Functions (the Controller)
  • Another Pass, Outside-In
    • A Quick Restructure of Our Template Composition
    • An Early Return So Were Refactoring Against Green
    • Factoring Out Two Template includes
    • Designing Our API Using the Template
    • Moving Down to the Next Layer: What the View Passes to the Template
  • The Next Requirement from the Views Layer: New Lists Should Record Owner
    • A Decision Point: Whether to Proceed to the Next Layer with a Failing Test
  • Moving Down to the Model Layer
  • Final Step: Feeding Through the .name API from the Template
• 25. CI: Continuous Integration
  • CI in Modern Development Workflows
  • Choosing a CI Service
  • Getting Our Code into GitLab
    • Signing Up
    • Starting a Project
    • Pushing Our Code Up Using Git Push
  • Setting Up a First Cut of a CI Pipeline
  • First Build! (and First Failure)
    • Trying to Reproduce a CI Error Locally
    • Enabling Debug Logs for Selenium/Firefox/Webdriver
    • Enabling Headless Mode for Firefox
  • A Common Bugbear: Flaky Tests
  • Taking Screenshots
  • Saving Build Outputs (or Debug Files) as Artifacts
  • If in Doubt, Try Bumping the Timeout!
  • A Successful Python Test Run
  • Running Our JavaScript Tests in CI
    • Installing Node.js
    • Installing and Configuring the Jasmine Browser Runner
    • Adding a Build Step for JavaScript
  • Tests Now Pass
  • Some Things We Didnt Cover
    • Defining a Docker Image for CI
    • Caching
    • Automated Deployment, aka Continuous Delivery (CD)
• 26. The Token Social Bit, the Page Pattern, and an Exercise for the Reader
  • An FT with Multiple Users, and addCleanup
  • The Page Pattern
  • Extend the FT to a Second User, and the My Lists Page
  • An Exercise for the Reader
    • Step-by-Step Guide
• 27. Fast Tests, Slow Tests, and Hot Lava
  • Why Do We Test? Our Desiderata for Effective Tests
    • Confidence and Correctness (Preventing Regression)
    • A Productive Workflow
    • Driving Better Design
  • Were Our Unit Tests Integration Tests All Along? What Is That Warm Glow Coming from the Database?
    • Weve Been in the Sweet Spot
    • What Is a True Unit Test? Does it Matter?
    • Integration and Functional Tests Get Slower Over Time
    • Were Not Getting the Full Potential Benefits of Testing
  • The Ideal of the Test Pyramid
  • Avoiding Mock Hell
  • The Actual Solutions Are Architectural
    • Ports and Adapters/Hexagonal/Onion/Clean Architecture
    • Functional Core, Imperative Shell
    • The Central Conceit: These Architectures Are Better
  • The Hardest Part: Knowing When to Make the Switch
  • Wrap-Up
    • Further Reading
• Obey the Testing Goat!
  • Testing Is Hard
    • Keep Your CI Builds Green
    • Take Pride in Your Tests, as You Do in Your Code
    • Remember to Tip the Bar Staff
  • Dont Be a Stranger!
• Bibliography
• A. Cheat Sheet
  • Initial Project Setup
  • The Basic TDD Workflow: Red/Green/Refactor
  • Moving Beyond Dev-Only Testing
  • General Testing Best Practices
  • Selenium/Functional Testing Best Practices
  • Outside-In
  • The Test Pyramid
• B. What to Do Next
  • Switch to Postgres
  • Run Your Tests Against Different Browsers
  • The Django Admin Site
  • Write Some Security Tests
  • Test for Graceful Degradation
  • Caching and Performance Testing
  • JavaScript Frameworks
  • Async and Websockets
  • Switch to Using pytest
  • Check Out coverage.py
  • Client-Side Encryption
  • Your Suggestion Here
• C. Source Code Examples
  • Full List of Links for Each Chapter
  • Using Git to Check Your Progress
  • Downloading a ZIP File for a Chapter
  • Dont Let it Become a Crutch!
• Index

pokaż cały spis treści

ukryj recenzje