book

Test-Driven Development with Python

Name: Test-Driven Development with Python
Author: Harry J.W. Percival
ISBN: 9781449364823

by Harry J.W. Percival

June 2014

Intermediate to advanced

480 pages

10h 37m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Praise for Test-Driven Development with Python
Preface
Why I Wrote a Book About Test-Driven DevelopmentAims of This BookOutlineConventions Used in This BookUsing Code ExamplesSafari® Books OnlineContacting O’Reilly
Prerequisites and Assumptions
Python 3 and ProgrammingHow HTML WorksJavaScriptRequired Software InstallationsGit’s Default Editor, and Other Basic Git ConfigRequired Python Packages
Companion Video
Acknowledgments
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 TestGetting Django Up and RunningStarting a Git Repository
2. Extending Our Functional Test Using the unittest Module
Using a Functional Test to Scope Out a Minimum Viable AppThe Python Standard Library’s unittest ModuleImplicit waitsCommit
3. Testing a Simple Home Page with Unit Tests
Our First Django App, and Our First Unit TestUnit Tests, and How They Differ from Functional TestsUnit Testing in DjangoDjango’s MVC, URLs, and View FunctionsAt Last! We Actually Write Some Application Code!urls.pyUnit Testing a ViewThe Unit-Test/Code Cycle
4. What Are We Doing with All These Tests?
Programming Is like Pulling a Bucket of Water up from a WellUsing Selenium to Test User InteractionsThe “Don’t Test Constants” Rule, and Templates to the RescueRefactoring to Use a TemplateOn RefactoringA Little More of Our Front PageRecap: The TDD Process

5. Saving User Input
Wiring Up Our Form to Send a POST RequestProcessing a POST Request on the ServerPassing Python Variables to Be Rendered in the TemplateThree Strikes and RefactorThe Django ORM and Our First ModelOur First Database MigrationThe Test Gets Surprisingly FarA New Field Means a New MigrationSaving the POST to the DatabaseRedirect After a POSTBetter Unit Testing Practice: Each Test Should Test One ThingRendering Items in the TemplateCreating Our Production Database with migrate
6. Getting to the Minimum Viable Site
Ensuring Test Isolation in Functional TestsRunning Just the Unit TestsSmall Design When NecessaryYAGNI!RESTImplementing the New Design Using TDDIterating Towards the New DesignTesting Views, Templates, and URLs Together with the Django Test ClientA New Test ClassA New URLA New View FunctionGreen? RefactorA Separate Template for Viewing ListsAnother URL and View for Adding List ItemsA Test Class for New List CreationA URL and View for New List CreationRemoving Now-Redundant Code and TestsPointing Our Forms at the New URLAdjusting Our ModelsA Foreign Key RelationshipAdjusting the Rest of the World to Our New ModelsEach List Should Have Its Own URLCapturing Parameters from URLsAdjusting new_list to the New WorldOne More View to Handle Adding Items to an Existing ListBeware of Greedy Regular Expressions!The Last New URLThe Last New ViewBut How to Use That URL in the Form?A Final Refactor Using URL includes
II. Web Development Sine Qua Nons
7. Prettification: Layout and Styling, and What to Test About It
What to Functionally Test About Layout and StylePrettification: Using a CSS FrameworkDjango Template InheritanceIntegrating BootstrapRows and ColumnsStatic Files in DjangoSwitching to StaticLiveServerTestCaseUsing Bootstrap Components to Improve the Look of the SiteJumbotron!Large InputsTable StylingUsing Our Own CSSWhat We Glossed Over: collectstatic and Other Static DirectoriesA Few Things That Didn’t Make It
8. Testing Deployment Using a Staging Site
TDD and the Danger Areas of DeploymentAs Always, Start with a TestGetting a Domain NameManually Provisioning a Server to Host Our SiteChoosing Where to Host Our SiteSpinning Up a ServerUser Accounts, SSH, and PrivilegesInstalling NginxConfiguring Domains for Staging and LiveUsing the FT to Confirm the Domain Works and Nginx Is RunningDeploying Our Code ManuallyAdjusting the Database LocationCreating a VirtualenvSimple Nginx ConfigurationCreating the Database with migrateGetting to a Production-Ready DeploymentSwitching to GunicornGetting Nginx to Serve Static FilesSwitching to Using Unix SocketsSwitching DEBUG to False and Setting ALLOWED_HOSTSUsing Upstart to Make Sure Gunicorn Starts on BootSaving Our Changes: Adding Gunicorn to Our requirements.txtAutomating“Saving Your Progress”
9. Automating Deployment with Fabric
Breakdown of a Fabric Script for Our DeploymentTrying It OutDeploying to LiveNginx and Gunicorn Config Using sedGit Tag the ReleaseFurther Reading
10. Input Validation and Test Organisation
Validation FT: Preventing Blank ItemsSkipping a TestSplitting Functional Tests out into Many FilesRunning a Single Test FileFleshing Out the FTUsing Model-Layer ValidationRefactoring Unit Tests into Several FilesUnit Testing Model Validation and the self.assertRaises Context ManagerA Django Quirk: Model Save Doesn’t Run ValidationSurfacing Model Validation Errors in the ViewChecking Invalid Input Isn’t Saved to the DatabaseDjango Pattern: Processing POST Requests in the Same View as Renders the FormRefactor: Transferring the new_item Functionality into view_listEnforcing Model Validation in view_listRefactor: Removing Hardcoded URLsThe {% url %} Template TagUsing get_absolute_url for Redirects
11. A Simple Form
Moving Validation Logic into a FormExploring the Forms API with a Unit TestSwitching to a Django ModelFormTesting and Customising Form ValidationUsing the Form in Our ViewsUsing the Form in a View with a GET RequestA Big Find and ReplaceUsing the Form in a View That Takes POST RequestsAdapting the Unit Tests for the new_list ViewUsing the Form in the ViewUsing the Form to Display Errors in the TemplateUsing the Form in the Other ViewA Helper Method for Several Short TestsUsing the Form’s Own Save Method
12. More Advanced Forms
Another FT for Duplicate ItemsPreventing Duplicates at the Model LayerA Little Digression on Queryset Ordering and String RepresentationsRewriting the Old Model TestSome Integrity Errors Do Show Up on SaveExperimenting with Duplicate Item Validation at the Views LayerA More Complex Form to Handle Uniqueness ValidationUsing the Existing List Item Form in the List View
13. Dipping Our Toes, Very Tentatively, into JavaScript
Starting with an FTSetting Up a Basic JavaScript Test RunnerUsing jQuery and the Fixtures DivBuilding a JavaScript Unit Test for Our Desired FunctionalityJavascript Testing in the TDD CycleColumbo Says: Onload Boilerplate and NamespacingA Few Things That Didn’t Make It
14. Deploying Our New Code
Staging DeployLive DeployWhat to Do If You See a Database ErrorWrap-Up: git tag the New Release
III. More Advanced Topics
15. User Authentication, Integrating Third-Party Plugins, and Mocking with JavaScript
Mozilla Persona (BrowserID)Exploratory Coding, aka “Spiking”Starting a Branch for the SpikeFrontend and JavaScript CodeThe Browser-ID ProtocolThe Server Side: Custom AuthenticationDe-spikingA Common Selenium Technique: Explicit WaitsReverting Our Spiked CodeJavaScript Unit Tests Involving External Components: Our First Mocks!Housekeeping: A Site-Wide Static Files FolderMocking: Who, Why, What?NamespacingA Simple Mock to Unit Tests Our initialize FunctionMore Advanced MockingUsing a sinon.js mock to check we call the API correctlyChecking Call ArgumentsQUnit setup and teardown, Testing AjaxLogoutMore Nested Callbacks! Testing Asynchronous Code
16. Server-Side Authentication and Mocking in Python
A Look at Our Spiked Login ViewMocking in PythonTesting Our View by Mocking Out authenticateChecking the View Actually Logs the User InDe-spiking Our Custom Authentication Backend: Mocking Out an Internet Request1 if = 1 More TestPatching at the Class LevelBeware of Mocks in Boolean ComparisonsCreating a User if NecessaryThe get_user MethodA Minimal Custom User ModelA Slight DisappointmentTests as DocumentationUsers Are AuthenticatedThe Moment of Truth: Will the FT Pass?Finishing Off Our FT, Testing Logout
17. Test Fixtures, Logging, and Server-Side Debugging
Skipping the Login Process by Pre-creating a SessionChecking It WorksThe Proof Is in the Pudding: Using Staging to Catch Final BugsSetting Up LoggingFixing the Persona BugManaging the Test Database on StagingA Django Management Command to Create SessionsGetting the FT to Run the Management Command on the ServerAn Additional Hop via subprocessBaking In Our Logging CodeUsing Hierarchical Logging ConfigWrap-Up
18. Finishing “My Lists”: Outside-In TDD
The Alternative: “Inside Out”Why Prefer “Outside-In”?The FT for “My Lists”The Outside Layer: Presentation and TemplatesMoving Down One Layer to View Functions (the Controller)Another Pass, Outside-InA Quick Restructure of the Template Inheritance HierarchyDesigning Our API Using the TemplateMoving Down to the Next Layer: What the View Passes to the TemplateThe Next “Requirement” from the Views Layer: New Lists Should Record OwnerA Decision Point: Whether to Proceed to the Next Layer with a Failing TestMoving Down to the Model LayerFinal Step: Feeding Through the .name API from the Template
19. Test Isolation, and “Listening to Your Tests”
Revisiting Our Decision Point: The Views Layer Depends on Unwritten Models CodeA First Attempt at Using Mocks for IsolationUsing Mock side_effects to Check the Sequence of EventsListen to Your Tests: Ugly Tests Signal a Need to RefactorRewriting Our Tests for the View to Be Fully IsolatedKeep the Old Integrated Test Suite Around as a Sanity CheckA New Test Suite with Full IsolationThinking in Terms of CollaboratorsMoving Down to the Forms LayerKeep Listening to Your Tests: Removing ORM Code from Our ApplicationFinally, Moving Down to the Models LayerBack to ViewsThe Moment of Truth (and the Risks of Mocking)Thinking of Interactions Between Layers as “Contracts”Identifying Implicit ContractsFixing the OversightOne More TestTidy Up: What to Keep from Our Integrated Test SuiteRemoving Redundant Code at the Forms LayerRemoving the Old Implementation of the ViewRemoving Redundant Code at the Forms LayerConclusions: When to Write Isolated Versus Integrated TestsLet Complexity Be Your GuideShould You Do Both?Onwards!
20. Continuous Integration (CI)
Installing JenkinsConfiguring Jenkins SecurityAdding Required PluginsTelling Jenkins where to find Python 3 and XvfbSetting Up Our ProjectFirst Build!Setting Up a Virtual Display so the FTs Can Run HeadlessTaking ScreenshotsA Common Selenium Problem: Race ConditionsRunning Our QUnit JavaScript Tests in Jenkins with PhantomJSInstalling nodeAdding the Build Steps to JenkinsMore Things to Do with a CI Server
21. The Token Social Bit, the Page Pattern, and an Exercise for the Reader
An FT with Multiple Users, and addCleanupImplementing the Selenium Interact/Wait PatternThe Page PatternExtend the FT to a Second User, and the “My Lists” PageAn Exercise for the Reader
22. Fast Tests, Slow Tests, and Hot Lava
Thesis: Unit Tests Are Superfast and Good Besides ThatFaster Tests Mean Faster DevelopmentThe Holy Flow StateSlow Tests Don’t Get Run as Often, Which Causes Bad CodeWe’re Fine Now, but Integrated Tests Get Slower Over TimeDon’t Take It from MeAnd Unit Tests Drive Good DesignThe Problems with “Pure” Unit TestsIsolated Tests Can Be Harder to Read and WriteIsolated Tests Don’t Automatically Test IntegrationUnit Tests Seldom Catch Unexpected BugsMocky Tests Can Become Closely Tied to ImplementationBut All These Problems Can Be OvercomeSynthesis: What Do We Want from Our Tests, Anyway?CorrectnessClean, Maintainable CodeProductive WorkflowEvaluate Your Tests Against the Benefits You Want from ThemArchitectural SolutionsPorts and Adapters/Hexagonal/Clean ArchitectureFunctional Core, Imperative ShellConclusion
Obey the Testing Goat!
Testing Is HardKeep Your CI Builds GreenTake Pride in Your Tests, as You Do in Your CodeRemember to Tip the Bar StaffDon’t Be a Stranger!
A. PythonAnywhere
Starting a virtualenvRunning Firefox Selenium Sessions with XvfbSetting Up Django as a PythonAnywhere Web AppCleaning Up /tmpScreenshotsThe Deployment Chapter
B. Django Class-Based Views
Class-Based Generic ViewsThe Home Page as a FormViewUsing form_valid to Customise a CreateViewA More Complex View to Handle Both Viewing and Adding to a ListThe Tests Guide Us, for a WhileUntil We’re Left with Trial and ErrorBack on TrackIs That Your Final Answer?Compare Old and NewBest Practices for Unit Testing CBGVs?Take-Home: Having Multiple, Isolated View Tests with Single Assertions Helps
C. Provisioning with Ansible
Installing System Packages and NginxConfiguring Gunicorn, and Using Handlers to Restart ServicesWhat to Do NextMove Deployment out of Fabric and into AnsibleUse Vagrant to Spin Up a Local VM
D. Testing Database Migrations
An Attempted Deploy to StagingRunning a Test Migration LocallyEntering Problematic DataCopying Test Data from the Live SiteConfirming the ErrorInserting a Data MigrationRe-creating the Old MigrationTesting the New Migrations TogetherConclusions
E. Behaviour-Driven Development (BDD)
What is BDD?Basic HousekeepingWriting an FT as a “Feature” using Gherkin SyntaxAs-a /I want to/So thatGiven/When/ThenNot Always A Perfect Fit!Coding the Step FunctionsGenerating Placeholder StepsFirst Step DefinitionsetUp and tearDown Equivalents in environment.pyAnother RunCapturing Parameters in StepsComparing the Inline-Style FTBDD Encourages Structured Test CodeThe Page Pattern as an AlternativeBDD Might Be Less Expressive than Inline CommentsWill Nonprogrammers Write Tests?Some Tentative Conclusions
F. Cheat Sheet
Initial Project SetupThe Basic TDD WorkflowMoving Beyond dev-only TestingGeneral Testing Best PracticesSelenium/Functional Testing Best PracticesOutside-In, Test Isolation Versus Integrated Tests, and Mocking
G. What to Do Next
Notifications—Both on the Site and by EmailSwitch to PostgresRun Your Tests Against Different Browsers404 and 500 TestsThe Django Admin SiteWrite Some Security TestsTest for Graceful DegradationCaching and Performance TestingJavaScript MVC FrameworksAsync and WebsocketsSwitch to Using py.testCheck out coverage.pyClient-Side EncryptionYour Suggestion Here
H. Bibliography
Index
Colophon
Copyright

Content preview from Test-Driven Development with Python

Chapter 20. Continuous Integration (CI)

As our site grows, it takes longer and longer to run all of our functional tests. If this continues, the danger is that we’re going to stop bothering.

Rather than let that happen, we can automate the running of functional tests by setting up a “Continuous Integration” or CI server. That way, in day-to-day development, we can just run the FT that we’re working on at that time, and rely on the CI server to run all the tests automatically, and let us know if we’ve broken anything accidentally. The unit tests should stay fast enough that we can keep running them every few seconds.

The CI server of choice these days is called Jenkins. It’s a bit Java, a bit crashy, a bit ugly, but it’s what everyone uses, and it has a great plugin ecosystem, so let’s get it up and running.

Installing Jenkins

There are several hosted-CI services out there that essentially provide you with a Jenkins server, ready to go. I’ve come across Sauce Labs, Travis, Circle-CI, ShiningPanda, and there are probably lots more. But I’m going to assume we’re installing everything on a server we control.

Note

It’s not a good idea to install Jenkins on the same server as our staging or production servers. Apart from anything else, we may want Jenkins to be able to reboot the staging server!

We’ll install the latest version from the official Jenkins apt repo, because the Ubuntu default still has a few annoying bugs with locale/unicode support, and it also doesn’t set itself up to listen ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Test-Driven Development with Python, 2nd Edition

Publisher Resources

ISBN: 9781449365141Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design