Sessions at PyCon US 2012 matching your filters

Your current filters are…

Clear
  • Stop Mocking, Start Testing

    by Augie Fackler and Nathaniel Manista

    Project Hosting at Google Code is a large, well-established system written mostly in Python. We'll share our battle-born convictions about creating tests for test-unfriendly code and the larger topic of testing.

    When launched, Project Hosting’s testing consisted of the stock Subversion test suite and a handful of ad hoc smoke test scripts that required starting the entire system and manually inspecting the test’s output.

    Over six years of codebase evolution, tests have been added with varying degrees of coverage and maintainability. Early system design decisions made adding tests difficult: the first tests added to the system used mock objects unwisely and large numbers of mock objects made refactoring costly in time and effort.

    Frustration with the difficulty of enhancing the service led us to reevaluate our testing practice and led to the discovery of better ways to test applications of this complexity. We will share our experiences with testing and discuss designing for maintainability and testability and appropriate use of testing tools such as frameworks and mocks.

    At 10:50am to 11:30am, Friday 9th March

    In D5, Santa Clara Convention Center

    Coverage video

  • Fast Test, Slow Test

    by Gary Bernhardt

    Most unit tests aren't and their authors suffer for it. What is a unit test, really? How can writing them prevent classic testing problems? If you do write them, what trade-offs are you implicitly making?

    Your unit test suite takes three minutes to run 500 tests. On a modern CPU, that's just shy of a billion instructions per test. Can something that takes a billion CPU instructions really be called a "unit"? What is that suite really testing?

    Many (and probably most) unit testing failures are related to size. Most common are the suite that takes half an hour to run (so no one runs it), the suite whose runtime scales like lines_of_code^2 (so, again, no one runs it), and the suite that requires huge maintenance for small changes (leading to the "testing is slow" myth).

    This talk is about the "unit" in "unit test": what does it really mean, why do we care, and how does it prevent the three crippling problems above? And, of course, if we do shift our focus toward unit tests, what trade-offs are we really making?

    At 11:30am to 12:10pm, Friday 9th March

    In D5, Santa Clara Convention Center

  • pytest - rapid and simple testing with Python

    by Holger Krekel

    The py.test tool presents a rapid and simple way to write tests. This talks introduces common testing terms, basic examples and unique pytest features for writing unit- or functional tests: assertions and dependency injection mechanisms. We also look at other features like distributing test load, new plugins and reasons why some Redhat and Mozilla people choose pytest over other approaches.

    The py.test tool presents a rapid and simple way to write tests for your Python code. This talks introduces some common testing terminology and basic pytest usage. Moreover, it discusses some unique pytest features for writing unit- or functional tests. For unit tests, the simple Python "assert" statement is used for coding assertions. As of 2011, this assert support has been perfected for Python 2.6 or higher, finally removing what some people have formerly called "magic side effects". For writing functional or acceptance tests py.test features a unique depdendency injection mechanism for managing test resources. The talk shows how to setup these resources and how to configure it via command line options. More recently, QA folks from Mozilla and Redhat QA people have endorsed come to appreciate these unique features and the general customizability. The talk concludes with a look on other features like distributing test load and other recently released plugins.

    This is the planned series of topics:

    unit- and functional testing

    why pytest and not Python packaged unittest package?

    simple test example and assertions

    example of dependency injection

    example usage from webqa mozilla project

    mocking and monkeypatching

    distributed test load to processors

    non-python test discovery

    customized reporting

    outlook on future releases

    At 2:40pm to 3:20pm, Friday 9th March

    In D5, Santa Clara Convention Center

  • Fake It Til You Make It: Unit Testing Patterns With Mocks and Fakes

    by Brian K. Jones

    In this talk, aimed at intermediate Pythonistas, we'll have a look at some common, simple patterns in code, and the testing patterns that go with them. We'll also discover what makes some code more testable than others, and how mocks and fakes can help isolate the code to be tested (and why you want to do that). Finally, we'll touch on some tools to help make writing and running tests easier.

    Overview
    You've heard the gospel of 'test, test, test!' over and over again, and may have even felt some jealousy or guilt because you're not using Test-Driven Development. Maybe you've even seen talks or read blog posts about writing 'testable code', but it just hasn't sunk in.

    The reality is that writing effective unit tests can be somewhat difficult to wrap your head around. What's a unit test? When is a unit test not a unit test? What's a functional test? When is a Mock really a fake or stub? There's a good bit of lingo, a fair amount of religion, but not enough instruction on effective testing patterns and idiomatic, Pythonic testing practices.

    As programming and application architecture is heavily influenced by the use of patterns, it's only logical that those patterns produce the side effect of making the way they'll be tested more predictable, and yet discussions of patterns regularly leave out coverage of testing, and most testing talks fail to link a methodology to patterns in the code. This changes now.

    In this talk, aimed at intermediate Pythonistas, we'll have a look at some common, simple patterns in code, and then have a look at the testing patterns that go with them. We'll also discover what makes some code more testable than others, and how mocks and fakes can help truly isolate the code to be tested (and why you really want to do that). Finally, we'll touch on some tools to help make writing and running tests easier.

    Outline
    What is a unit test? (3 minutes)
    Unit Test definition
    Unit tests vs. functional, integration, and acceptance tests
    Why Unit Tests? (3 minutes)
    "Why isolate the code?" (I get this question a lot)
    "But, I use functional tests & have 100% coverage!"
    Three pieces of code, and how to make it more testable. (8 minutes)
    Patterns in code, patterns in tests (15 minutes)
    A Simple datetime abstraction library, its patterns and tests.
    A REST Client Module, its patterns and tests
    A cmd-module-based command shell, its patterns and tests
    A microframework-based service, its patterns and tests
    Tools You Want to Use (5 minutes)
    Mock
    Nose
    Coverage
    Tox
    TBD (Possibly PyCharm's test support, which is getting good w/ 2.0, but there are many candidates)

    At 3:20pm to 4:05pm, Friday 9th March

    In D5, Santa Clara Convention Center