Testing & TDD
Edsger Dijkstra said testing can show the presence of these, but never their absence.
Bugs
This principle warns that duplication is the root of all evil.
DRY - Don't Repeat Yourself
XP planning begins with these short descriptions of user needs.
User Stories
This agile practice uses a Driver and a Copilot working at one computer.
Pair programming
This principle states that a class should have only one reason to change.
SRP
Zero, One, Many, Boundaries, Interfaces, Exceptions, and Scenarios form this testing acronym.
ZOMBIES
“Always implement things when you need them” summarizes this design philosophy.
A quick, disposable prototype made to learn unfamiliar technology is known as this.
Spike
In pair programming, this must occur periodically to share roles.
Swapping roles every X minutes
More of this between modules is bad; less is good.
Coupling
These tests check how multiple classes work together after each is individually verified.
Medium Tests
This concept ensures internal implementation details are hidden—starting with private visibility.
Encapsulation
Agile Principle #7 says this is the principal measure of progress.
Working software
This benefit of pairing reduces the chance of mistakes and increases code quality in real time.
Real-time code review
In Java naming conventions, these identifiers use PascalCase.
Class names
In TDD, this must always be done before writing any production code.
Write a failing test
Tasks within a module should be closely related according to this clean-code property.
Cohesion
According to Agile Principle #10, this concept—aligned with Occam’s Razor—is essential.
Simplicity
You are not just a developer but also this, helping your partner succeed.
Educator/partner
These comments—such as JavaDocs or legal notices—are acceptable in clean code.
Legal documents and Java docs