Python测试驱动开发(影印版) 东南大学出版社 mobi 下载 网盘 caj lrf pdf txt 阿里云

本书通过从头开发一个真实的Web应用，介绍了Python测试驱动开发的优势。读者将学会如何在构建应用的每个部分之前编写和运行测试，然后用最少的代码通过这些测试。

Prerequisites and Assumptions

Companion Video

Acknowledgments

Part 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 Library's unittest Module

Implicit waits

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

Django's MVC， URLs， and View Functions

At Last！ We Actually Write Some Application Code！

urls.py

Unit Testing a View

The Unit—Test／Code Cycle

4.What Are We Doing with All These Tests？

Programming Is like Pulling a Bucket of Water up from a Well

Using Selenium to Test User Interactions

The "Don't Test Constants" Rule， and Templates to the Rescue

Refactoring to Use a Template

On Refactoring

A Little More of Our Front Page

Recap： The TDD Process

5.Saving User Input

Wiring Up Our Form to Send a POST Request

Processing a POST Request on the Server

Passing Python Variables to Be Rendered in the Template

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

6.Getting to the Minimum Viable Site

Ensuring Test Isolation in Functional Tests

Running lust the Unit Tests

Small Design When Necessary

YAGNI！

REST

Implementing the New Design Using TDD

Iterating Towards the New Design

Testing Views， Templates， and URLs Together with the Django Test Client

A New Test Class

A New URL

A New View Function

A Separate Template for Viewing Lists

Another URL and View 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

Pointing Our Forms at the New URL

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

One More View to Handle Adding Items to an Existing List

Beware of Greedy Regular Expressions！

The Last New URL

The Last New View

But How to Use That URL in the Form？

A Final Refactor Using URL includes

Part Ⅱ.Web Development Sine Qua Nons

7.Prettification： Layout and Styling， and What to Test About It

What to Functionally Test About Layout and Style

Pretti Fication： Using a CSS Framework

Django Template Inheritance

Integrating Bootstrap

Rows and Columns

Static Files in Django

Switching to Static Live Server Test Case

Using Bootstrap Components to Improve the Look of the Site

Jumbotron！

Large Inputs

Table Styling

Using Our Own CSS

What We Glossed Over： collectstatic and Other Static Directories

A Few Things That Didn't Make It

8.Testing Deployment Using a Staging Site

TDD and the Danger Areas of Deployment

As Always， Start with a Test

Getting a Domain Name

Manually Provisioning a Server to Host Our Site

Choosing Where to Host Our Site

Spinning Up a Server

User Accounts， SSH， and Privileges

Installing Nginx

Configuring Domains for Staging and Live

Using the FT to Confirm the Domain Works and Nginx Is Running

Deploying Our Code Manually

Adjusting the Database Location

Creating a Virtualenv

Simple Nginx Configuration

Creating the Database with migrate

Getting to a Production—Ready Deployment

Switching to Gunicorn

Getting Nginx to Serve Static Files

Switching to Using Unix Sockets

Switching DEBUG to False and Setting ALLOWED_HOSTS

Using Upstart to Make Sure Gunicorn Starts on Boot

Saving Our Changes： Adding Gunicorn to Our requirements.txt

Automating

"Saving Your Progress"

9.Automating Deployment with Fabric

Breakdown of a Fabric Script for Our Deployment

Trying It Out

Deploying to Live

Nginx and Gunicorn Config Using sed

Git Tag the Release

Further Reading

10.Input Validation and Test Organisation

Validation FT： Preventing Blank Items

Skipping a Test

Splitting Functional Tests out into Many Files

Running a Single Test File

Fleshing Out the FT

Using Model—Layer Validation

Refactoring Unit Tests into Several Files

Unit Testing Model Validation and the self assert Raises Context Manager

A Django Quirk： Model Save Doesn't Run Validation

Surfacing Model Validation Errors in the View

Checking Invalid Input Isn't Saved to the Database

Django Pattern： Processing POST Requests in the Same View as Renders the Form

Refactor： Transferring the new_item Functionality into view_list

Enforang Model Validation in view_list

Refactor： Removing Hardcoded URLs

The {% url %} Template Tag

Using get_absolute_url for Redirects

11.A Simple Form

Moving Validation Logic into a Form

Exploring the Forms API with a Unit Test

Switching to a Django Model Form

Testing and Customising Form Validation

Using the Form in Our Views

Using the Form in a View with a GET Request

A Big Find and Replace

Using the Form in a View That Takes POST Requests

Adapting the Unit Tests for the new_list View

Using the Form in the.View

Using the Form to Display Errors in the Template

Using the Form in the Other View

A Helper Method for Several Short Tests

Using the Form's Own Save Method

12.More Advanced Forms

Another FT for Duplicate Items

Preventing Duplicates at the Model Layer

A Little Digression on Queryset Ordering and String Representations

Rewriting the Old Model Test

Some Integrity Errors Do 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

13.Dipping Our Toes， Very Tentatively， into Java Script

Starting with an FT

Setting Up a Basic Java Script Test Runner

Usingi Query and the Fixtures Div

Building a Java Script Unit Test for Our Desired Functionality

Java Testing in the TDD Cycle

Columbo Says： Onload Boilerplate and Namespacing

A Few Things That Didn't Make It

14.Deploying Our New Code

Staging Deploy

Live Deploy

What to Do If You See a Database Error

Wrap—Up： git tag the New Release

……

Part Ⅲ.More Advanced Topics

Index

Harry J.W.Percival，在PyhonAnywhere LLP工作，并带着全部激情和热忱在优选的演讲、培训和会议中传播测试驱动开发的福音。他持有利物浦大学的计算机科学硕士学位以及剑桥大学的哲学硕士学位。

暂无出版社相关信息，正在全力查找中！

暂无相关书籍摘录，正在全力查找中！

在线阅读地址：Python测试驱动开发(影印版) 东南大学出版社在线阅读

在线听书地址：Python测试驱动开发(影印版) 东南大学出版社在线收听

在线购买地址：Python测试驱动开发(影印版) 东南大学出版社在线购买

Do you know why the Django mascot is a pony? The story is that Django comes with so many things you want: an ORM, all sorts of middleware, the admin site … "What else do you want, a pony?" Well, Gunicorn stands for "Green Unicorn", which I guess is what you’d want next if you already had a pony…

On the Pros and Cons of Different Types of Test, and Decoupling ORM code

Functional tests

Provide the best guarantee that your application really works correctly, from the point of view of the user.

But: it’s a slower feedback cycle,

And they don’t necessarily help you write clean code.

Integrated tests (reliant on, eg, the ORM or the Django Test Client)

Are quick to write,

Easy to understand,

Will warn you of any integration issues,

But may not always drive good design (that’s up to you!).

And are usually slower than isolated tests

Isolated ("mocky") tests

These involve the most hard work.

They can be harder to read and understand,

But: these are the best ones for guiding you towards better design.

And they run the fastest.

Decoupling our application from ORM code

When striving to write ...

So one way of getting what we want is to try and minimise the amount of our code that has to deal with boundaries. Then we test our core business logic with isolated tests and test our integration points with integrated tests.

Functional tests should help you build an application with the right functionality, and guarantee you never accidentally break it. Unit tests should help you to write code that’s clean and bug free.

We can start to settle into the TDD unit-test/code cycle now:

1. In the terminal, run the unit tests and see how they fail.

2. In the editor, make a minimal code change to address the current test failure.

And repeat!

Kent Beck (who basically invented TDD) uses the metaphor of lifting a bucket of water out of a well with a rope: when the well isn’t too deep, and the bucket isn’t very full, it’s easy. And even lifting a full bucket is pretty easy at first. But after a while, you’re going to get tired. TDD is like having a ratchet that lets you save your progress, take a break, and make sure you never slip backwards. That way you don’t have to be smart all the time.

...

TDD is a discipline, and that means it’s not something that comes naturally; because many of the payoffs aren’t immediate but only come in the longer term, you have to force yourself to do it in the moment. That’s what the image of the Testing Goat is supposed to illustrate—you need to be a bit bloody-minded about it.

书籍介绍

珀西瓦尔编*的《python测试驱动开发（影印版）（英文版）》这本实用指南带你从头至尾经历一个真实web应用开发的全过程，展示了python测试驱动开发（tdd）的优越性。你将学到如何在应用程序各部分被构建出来之前就编写并运行测试，然后开发* 少量的代码就让这些测试运行通过。结果得到什么？能够运行的简洁代码。 　　在书中，你将学到diango、selenium、git、 iquery和mock的基础知识，另外还有现代web开发技巧。如果你准备将自己的python技术提升到下一个层次，这本书清楚地展示了测试驱动开发是如何提倡简单设计并增进信心。 　　深入测试驱动开发工作流，包括单元测试／编码周期循环和重构 为类和函数使用单元测试，并为浏览器内的用户交互使用功能测试 学习何时与如何运用mock对象，以及单独和集成测试的优缺点 在开发用服务器上测试以及自动化部署 将测试运用到网站集成的第三方插件上去 使用一个持续集成环境来自动运行测试