DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Ping-Pong Pair Programming

Can you say that five times fast? Ping-pong pairing involves a back-and-forth between test and code and supports developers in doing test-first development.

David Bernstein user avatar by
David Bernstein
CORE ·
Jan. 05, 17 · Opinion
Like (6)
Save
Tweet
Share
10.31K Views

Join the DZone community and get the full member experience.

Join For Free

One pair programming configuration I like is called ping-pong pairing.

In ping-pong pairing, the driver writes a test for a behavior then asks the navigator to implement the behavior and make the test pass. Once completed, the keyboard is passed from driver to navigator and the new driver writes the next test for the new navigator to implement.

This back-and-forth between test and code, driver and navigator, can offer rich feedback when building a system. It also supports developers in doing test-first development.

One of the challenges with ping-pong pairing is making the time to refactor both code and tests. It’s easy to get on a forward momentum where features are being implemented, but we also have to take the time to step back and make sure our code is clean so it’s straightforward to maintain and work with in the future. This also applies to our tests.

I find that when doing TDD, I spend a fair amount of time refactoring my tests. Sometimes, I spend more time refactoring my tests than refactoring my code, but this is natural. Exercising a feature can be complex, so testing can be complex, too — but it’s well worth it to make tests straightforward and easy to read.

The two things I typically do to make my tests more readable are factor common set up behaviors into a common setup method and, for any additional functionality that is not shared among all tests, write helper methods that my test can call.

You might have heard me rant in the past about how helper methods have no place in the domain model. They’re orphaned behaviors because the developer who wrote them didn’t take the time to discover what object should actually possess those behaviors and instead they made a helper object hold those behaviors. Doing this distorts the domain model. It means that objects in our domain model are not being called out correctly and therefore the domain model is distorted and difficult to understand. So, it’s true: I am against helper methods in production code.

However, helper methods do have a place in test code. Test code is, after all, different than production code. It has a different purpose. It’s intended to exercise production code, so it makes complete sense for tests to have helper methods.

Tests are, after all, code, and they’re important code because they exercise a production system. We should write our tests with every bit as much care as we use to write production code.

Ping-pong pairing helps us keep an emphasis on both test and production code and can support pairs in doing TDD well.

Testing

Published at DZone with permission of David Bernstein, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Kotlin Is More Fun Than Java And This Is a Big Deal
  • Event Driven 2.0
  • 2023 Software Testing Trends: A Look Ahead at the Industry's Future
  • Secrets Management

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: