9. Unit Testing Patterns | Test Driven Python Development

Sign In Start Free Trial

Book Overview & Buying
Table Of Contents

Test Driven Python Development

By : Siddharta Govindaraj

4.4 (5)

Test Driven Python Development

4.4 (5)

By: Siddharta Govindaraj

Overview of this book

This book starts with a look at the test-driven development process, and how it is different from the traditional way of writing code. All the concepts are presented in the context of a real application that is developed in a step-by-step manner over the course of the book. While exploring the common types of smelly code, we will go back into our example project and clean up the smells that we find. Additionally, we will use mocking to implement the parts of our example project that depend on other systems. Towards the end of the book, we'll take a look at the most common patterns and anti-patterns associated with test-driven development, including integration of test results into the development process.

Preface

Preface

What this book covers

What you need for this book

Who this book is for

Conventions

Reader feedback

Customer support

Free Chapter

1. Getting Started with Test-Driven Development

1. Getting Started with Test-Driven Development

Prerequisites

Understanding test-driven development

Using TDD to build a stock alert application

Reorganizing the test code

Summary

2. Red-Green-Refactor – The TDD Cycle

2. Red-Green-Refactor – The TDD Cycle

Tests are executable requirements

Arrange-Act-Assert

Documenting our tests

Testing for exceptions

Exploring assert methods

Specific asserts versus generic asserts

Setup and teardown

Brittle tests

Refactoring the design

Refactoring tests

Exploring the Rule classes

Exercise

Summary

3. Code Smells and Refactoring

3. Code Smells and Refactoring

A dual crossover moving average

Implementing the dual crossover moving average

Identifying code smells

Refactoring

The importance of tests

Exercise

Wrapping up

Summary

4. Using Mock Objects to Test Interactions

4. Using Mock Objects to Test Interactions

Hand writing a simple mock

Using the Python mocking framework

Tying it all together

Summary

5. Working with Legacy Code

5. Working with Legacy Code

What is legacy code?

Understanding the code

Techniques to break dependencies

The cycle continues

Time to refactor

Summary

6. Maintaining Your Test Suite

6. Maintaining Your Test Suite

Goals of test maintenance

Organizing tests

Making tests readable

Writing tests closer to the domain

Summary

7. Executable Documentation with doctest

7. Executable Documentation with doctest

Our first doctest

Test failures

Testing for exceptions

Package-level doctests

Maintaining doctests

Limitations of doctest

How do doctests fit into the TDD process?

Summary

8. Extending unittest with nose2

8. Extending unittest with nose2

Getting started with nose2

Writing tests for nose2

nose2 plugins

Summary

9. Unit Testing Patterns

9. Unit Testing Patterns

Pattern – fast tests

Pattern – running a subset of tests

Pattern – using attributes

Pattern – expected failures

Pattern – data-driven tests

Pattern – integration and system tests

Pattern – spies

Summary

10. Tools to Improve Test-Driven Development

10. Tools to Improve Test-Driven Development

TDD tools

Integrating with build tools

Integrating with packaging tools

Distutils

Integrating with continuous integration tools

Other tools

IDE integration

Summary

A. Answers to Exercises

A. Answers to Exercises

Red-Green-Refactor – The TDD Cycle

Code Smells and Refactoring

B. Working with Older Python Versions

B. Working with Older Python Versions

Writing code that is compatible across versions

Running tests from the command line

Running the examples in this book

Index

Index

Pattern – expected failures

Sometimes, we have tests that are failing, but, for whatever reason, we don't want to fix it yet. It could be that we found a bug and wrote a failing test that demonstrates the bug (a very good practice), but we have decided to fix the bug later. Now, the whole test suite is failing.

On one hand, we don't want the suite to fail because we know this bug and want to fix it later. On the other hand, we don't want to remove the test from the suite because it reminds us that we need to fix the bug. What do we do?

Python's unittest module provides a solution: marking tests as expected failures. We can do this by applying the unittest.expectedFailure decorator to the test. The following is an example of it in action:

class AlertTest(unittest.TestCase):
    @unittest.expectedFailure
    def test_action_is_executed_when_rule_matches(self):
        goog = mock.MagicMock(spec=Stock)
        goog.updated = Event()
        goog.update.side_effect = \
            lambda date,...

CONTINUE READING

83

Tech Concepts

36

Programming languages

73

Tech Tools

Unlimited access to the largest independent learning library in tech of over 8,000 expert-authored tech books and videos.

Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.

50+ new titles added per month and exclusive early access to books as they are being written.

Test Driven Python Development

Search

Your notes and bookmarks