Testable by accident

I'm not going to argue for test-driven development. I've watched that argument go nowhere in enough rooms to know it isn't the lever.

Here's the lever instead. One class, written by one person in one sitting, where half the methods were trivial to test and the other half were miserable. Nothing separated them except where the data came from.

The easy half

// Everything it needs arrives as an argument.
public static Map<Id, PricebookEntry> bestByProduct(
  List<PricebookEntry> entries,
  Map<Id, Integer> rankByPricebook
) { ... }

To test that, you build a list in memory and call it. No fixture, no DML, no governor limits, no @TestSetup to age badly. You can write twelve cases for the price of one.

The miserable half

// Queries inside, decides inside, writes inside.
public static void applyPricingToWishlist(Id wishlistId) { ... }

To test that, you need a wishlist, an account, buyer groups, a store, price books, entries, and whatever validation rules those objects carry. Every one of those is a chance for the fixture to break later for reasons unrelated to pricing.

Same developer. Same afternoon. The difference isn't discipline, it's that one method takes its inputs and the other goes and gets them.

The question

So the question to ask at design time isn't "how will I test this." It's narrower:

Does this method fetch what it needs, or receive it?

You won't split every method. Something has to do the querying, and that something will be hard to test — that's fine, that's one thin method with one integration test around it. The win is that the decisions move into functions that take arguments, and decisions are where the bugs live.

That's most of the benefit people attribute to writing tests first, available to someone who writes tests afterwards like a normal person.

Next in this series. 3 · Data difficulty ladder prices the fixtures this post assumes you can build.