XP Engineering Practices: Pair Programming, TDD, Continuous Integration, and Refactoring

UPI Study › Courses › Software Engineering › Free lessons › Lesson 5.5 Free with a free account

XP Engineering Practices: Pair Programming, TDD, Continuous Integration, and Refactoring

Software Engineering · Chapter 5: Agile Methodology in PracticeSection 5.5 · lesson 35 of 1037 min · free with a free account

← The 5 Core Values of Extreme Programming and the Culture They CreateNext lesson: Comparing Agile Process Frameworks →

Earn 3 college credits for Software EngineeringRecommended for credit by NCCRS · Computer Science 301 · self-paced · one payment, lifetime access
Enroll in Software Engineering · $250 →Download the syllabus (PDF)

In this lesson

Pair programming, TDD, continuous integration, and refactoring.

  • Explain what XP adds to the generic agile lifecycle
  • Describe pair programming, and the driver and navigator roles
  • Describe the TDD cycle, and continuous integration
  • Explain why the 4 practices reinforce each other

Transcript

Everything said in the video, section by section (950 words). Read along, or search it.

Agile Methodology in Practice

XP Engineering Practices

The agile lifecycle says work happens in repeating cycles. But it does not say how the code itself gets written inside one. Extreme Programming answers that directly, with four tightly linked engineering practices. This section covers pair programming, test-driven development, continuous integration, and refactoring, and why they belong together.

Inside the Cycle

How the Code Gets Written

Extreme Programming, usually shortened to X P, focuses on how code gets produced, at a sustainable, high-quality pace. It cares more about that than about roles or scheduled events. Four of its best-known practices are pair programming, test-driven development, continuous integration, and a particular way of handling refactoring. They are meant to be used together, as a coherent system, not sampled individually from a menu. Each one makes the others more effective, and the protection X P is known for comes largely from that combination.

Pair Programming

2 People, 1 Keyboard

In pair programming, two people work together at a single workstation, on the same code, at the same time. One person, the driver, is actively typing. The other, the navigator, reviews each line as it is written, thinks ahead, and catches mistakes before they are ever committed. The two roles swap regularly, so both people stay actively engaged, rather than one simply watching.

Pair Programming

Review in Real Time

The value comes from review that happens continuously, in real time, rather than later, after the code is written. Problems get caught immediately, instead of being discovered in a separate review step. Knowledge about the code spreads across the team as the work happens, rather than depending on documentation written afterward. And because a second person is thinking through every decision as it is made, the code tends to be simpler, and more carefully considered.

Figure 1

Red, Green, Refactor

Test-driven development, or T D D, is a discipline about the order in which code gets written. First, write a small test for behavior that does not exist yet. The test necessarily fails. That is the red step. Next, write just enough code to make that test pass. That is the green step. Finally, improve the code's internal structure, while the now-passing test protects against breaking it. That is the refactor step. Then the loop starts again. Each pass often takes only minutes.

TDD in Miniature

The Test Comes First

Here is the cycle in miniature. First, the test. It checks that adding two and three gives five. Running it fails, because the add function does not exist yet. Then just enough code to pass. A function that returns the sum of its two inputs. Now the test passes. Notice what gets left behind. Every loop leaves a test in place. So a growing, trustworthy suite of automated tests builds up naturally, as the code is written, rather than as a separate activity afterward.

Continuous Integration

Merging Constantly, Not Eventually

Continuous integration is about keeping everyone's work together. Rather than letting pieces of work drift apart for days or weeks, everyone's changes are merged into one shared version of the code, many times a day. Each merge automatically triggers a fast check, typically the test suite built up through T D D, confirming that nothing has broken. The value is catching integration problems while they are still small and cheap to fix, rather than piling them into one large, painful merge later. The specific tools are a separate topic. The discipline is what matters. Merge often, check automatically, and keep the shared code working.

Worth Noticing

Each Practice Covers the Next

It is worth noticing how these practices depend on each other. Pairing catches a bad change before it is committed. T D D produces the safety net that makes fast checks meaningful. And continuous integration makes sure that safety net gets exercised constantly, not occasionally. Adopt just one of them, and most of the protection the whole system provides together is lost.

Refactoring in XP

The Third Beat of the Cycle

Refactoring means improving a piece of code's internal structure, without changing what it does from the outside. Inside X P, refactoring is not scheduled as separate cleanup work for later. It is the third beat of the T D D cycle, happening continuously. What makes frequent refactoring safe is the test suite that T D D produces. A change to the code's structure can be checked instantly against tests that already exist, giving real confidence that behavior has not quietly changed.

Table 1

The 4 Practices Together

Here are the four practices together. Pair programming is two people at one workstation, with continuous review. It catches problems at once, and spreads knowledge across the team. T D D writes a failing test, then the code to pass it, then refactors. It produces a trustworthy, growing test suite. Continuous integration merges everyone's changes many times a day, catching integration problems while they are small. And refactoring improves structure continuously, protected by the tests, so the codebase stays healthy without a cleanup phase. Together, they are what make embracing change genuinely safe. A team can respond to a changed requirement without dreading what else might break.

Key Terms

The Vocabulary of This Section

Let's lock in the key terms. Pair programming is two people working at one workstation on the same code, as driver and navigator, swapping roles regularly. Test-driven development means writing a failing test before the code that satisfies it, then refactoring, in a short, constantly repeated cycle. Continuous integration means merging everyone's changes into one shared version many times a day, each time checked automatically against the tests. And refactoring, in X P, is the continuous, test-protected improvement of code structure, built directly into the T D D cycle.

Key Takeaways

What to Carry Forward

To pull this together. Extreme Programming defines how code actually gets written inside each cycle. Pair programming gives continuous, real-time review, with the driver and navigator swapping roles regularly. T D D runs through red, green, and refactor, and leaves a trustworthy test suite behind. Continuous integration merges and checks everyone's work many times a day. And the four practices reinforce each other. Together, they make change safe.

About Software Engineering at UPI Study

Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.

Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →

Compare: Software Engineering vs Systems Analysis

Why take it here

Why students take Software Engineering with UPI Study

How professional software gets builtSoftware Engineering covers how teams turn requirements into working, maintainable software: process models, agile, requirements, design, testing, reliability and project management. It is a core course in computer science and software degrees.
Credit at a fraction of the priceThe same 3 credits can cost $750 or more at a US college. Here it is one payment, self-paced, with lifetime access.
Finish your degree soonerTransfer credits reduce the courses you still owe, so you can graduate earlier or lighten a heavy semester.
Strengthen an applicationA completed college-level course on an official transcript shows admissions and scholarship committees you can do the work.
Study on your own scheduleNo start dates, no deadlines. Watch the lessons, practice, and take the final when you are ready.
130,000+students helped with college creditsACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Where the credit goes

Universities that work with NCCRS

Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.

Thomas Edison State UniversityThomas Edison State UniversitySigned partnerUniversity of the PeopleUniversity of the PeopleSigned partnerCharter Oak State CollegeCharter Oak State CollegeSigned partnerStrayer UniversityStrayer UniversitySigned partnerColumbia Southern UniversityColumbia Southern UniversitySigned partnerIndiana TechIndiana TechSigned partnerPenn StatePenn StateWorks with NCCRSSouthern New Hampshire UniversitySouthern New Hampshire UniversityWorks with NCCRSSUNYSUNYWorks with NCCRS +many more cooperating universitiesFind my college →

Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.

FAQ

Questions students ask us

About XP Engineering Practices: Pair Programming, TDD, Continuous Integration, and Refactoring

What is pair programming and how do the driver and navigator roles work?
Pair programming is two people working at one workstation on the same code at the same time. The driver actively types, while the navigator reviews each line as it is written, thinks ahead, and catches mistakes before they are committed. The roles swap regularly so both stay engaged. The result is continuous review, shared knowledge, and often simpler code.
What is the red-green-refactor cycle in test-driven development?
Red-green-refactor is the core loop of test-driven development. First, write a small test for behavior that does not exist yet, so it fails (red). Next, write just enough code to make it pass (green). Finally, improve the code's structure while the passing test protects it (refactor). Each pass often takes only minutes and leaves a test behind.
What is continuous integration?
Continuous integration is the practice of merging everyone's changes into one shared version of the code many times a day, with each merge automatically triggering a fast check, typically the test suite. It catches integration problems while they are still small and cheap to fix, instead of letting work drift apart for days or weeks and ending in one large, painful merge.
Why should pair programming, TDD, and continuous integration be used together?
XP's engineering practices are designed as a system in which each covers the next. Pairing catches a bad change before it is committed, TDD builds the test suite that makes fast checks meaningful, continuous integration exercises those tests constantly, and refactoring relies on them to stay safe. Adopting only one loses most of the protection the combination provides.

About the Software Engineering course

How many college credits is Software Engineering?
Software Engineering (Computer Science 301) carries a NCCRS credit recommendation for 3 semester credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
How much does Software Engineering cost and what is included?
$250, paid once, with lifetime access: all 103 video lessons, a practice quiz after each, the graded work and final exam, and an official transcript when you finish. Students who want several courses choose UPI Study PRO instead.
Which universities accept UPI Study credits?
UPI Study has signed partner agreements with universities such as Thomas Edison State University, University of the People and Charter Oak State College, and works with universities such as Penn State, SNHU and SUNY. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities. Use "Find my college" on this page to check yours.
How long does Software Engineering take?
It is self-paced with no deadlines. The 103 lessons total about 11 hours of video; most students add reading and practice time and finish in a few weeks to a few months, on their own schedule.
How are the exams done?
Quizzes and assignments are online in the course. The final exam is taken online with proctoring; a person on the UPI Study team checks assignments, usually within two days.
How do my credits reach my college?
When the course shows 100% complete, request the official transcript from your dashboard. It is sent to the college you name, and you can send it to more than one. Check your college first with "Find my college" on this page, or ask Athena.

Ready for the full course? Earn 3 credits in Software Engineering.

103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.

Enroll in Software Engineering →Download the syllabusEvery course with PRO →
Software Engineering
3 credits · NCCRSEnroll →