List and table styles to legacy-code-testing-characterization-tests-seams article

Author: webstackdev

src/content/articles/legacy-code-testing-characterization-tests-seams/index.mdx

@@ -18,11 +18,11 @@ Here's the paradox every developer faces with legacy code: you can't refactor sa
 
 The code is "untestable." Except it isn't.
 
-Two techniques unlock almost any legacy codebase: __characterization tests__ and __seam identification__. You don't need to understand the code to test it, and you don't need to refactor before you can write your first test. These techniques form the foundation that makes everything else possible.
+<Highlighter>Two techniques unlock almost any legacy codebase: __characterization tests__ and __seam identification__. You don't need to understand the code to test it, and you don't need to refactor before you can write your first test.</Highlighter> These techniques form the foundation that makes everything else possible.
 
 ## Characterization Tests: Document Before You Judge
 
-Traditional unit tests verify that code does what it __should__ do — you write a test based on a specification, and the test fails if the code doesn't match. Characterization tests flip this: they capture what the code __actually__ does, regardless of intent. You're not testing against a spec; you're documenting observed behavior.
+Traditional unit tests verify that code does what it _should_ do — you write a test based on a specification, and the test fails if the code doesn't match. Characterization tests flip this: they capture what the code _actually_ does, regardless of intent. You're not testing against a spec; you're documenting observed behavior.
 
 The distinction matters for legacy code. You don't have a spec. The original authors are gone. The code has undocumented edge cases, implicit business rules buried in conditionals, and behaviors that might be bugs or might be features — you can't tell. Characterization tests don't try to answer "is this correct?" They answer "what does this do?" and lock it in.
 
@@ -66,26 +66,28 @@ Consider a method that sends emails. The email-sending code is deep inside a 500
 ### The Four Seam Types
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: 'Object seams',
-      text: 'are the most common and usually the cleanest. You pass a dependency through a constructor or method parameter, and the enabling point is the call site where you can pass a different implementation. This is the foundation of dependency injection. Most languages and frameworks have idiomatic ways to create object seams:',
+      text: 'The most common and usually the cleanest. You pass a dependency through a constructor or method parameter, and the enabling point is the call site where you can pass a different implementation. This is the foundation of dependency injection. Most languages and frameworks have idiomatic ways to create object seams:',
     },
   ]}
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
+    figure: 'Object seam techniques by language and framework.',
     thead: {
       th: ['Language/Framework', 'Object Seam Technique'],
     },
     tbody: {
       tr: [
         {
           th: 'Ruby',
-          td: ['Default arguments in `initialize`'],
+          td: ['Default arguments in <span class="font-mono">initialize</span>'],
         },
         {
           th: 'C# / Java',
@@ -97,40 +99,40 @@ Consider a method that sends emails. The email-sending code is deep inside a 500
         },
         {
           th: 'TypeScript',
-          td: ['Optional parameters with nullish coalescing (`??`)'],
+          td: ['Optional parameters with nullish coalescing (<span class="font-mono">??</span>)'],
         },
         {
           th: 'Spring Boot',
-          td: ['`@Autowired` with test `@Configuration` bindings'],
+          td: ['<span class="font-mono">@Autowired</span> with test <span class="font-mono">@Configuration</span> bindings'],
         },
         {
           th: 'Laravel',
-          td: ['Service container with `$this->app->bind()` in tests'],
+          td: ['Service container with <span class="font-mono">$this->app->bind()</span> in tests'],
         },
         {
           th: '.NET',
-          td: ['`IServiceCollection` with test service registration'],
+          td: ['<span class="font-mono">IServiceCollection</span> with test service registration'],
         },
       ],
     },
-    figure: 'Object seam techniques by language and framework.',
   }}
 />
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
+  startNumber={2}
   items={[
     {
       lead: 'Link seams',
-      text: 'operate at the module level. In Ruby, you can use `stub_const` to replace a class entirely. In TypeScript/JavaScript, Jest\'s `jest.mock()` intercepts imports. The enabling point is the test setup. Link seams are powerful but fragile — they couple tests to implementation details like class names.',
+      text: 'These operate at the module level. In Ruby, you can use <span class="font-mono">stub_const</span> to replace a class entirely. In TypeScript/JavaScript, Jest\'s <span class="font-mono">jest.mock()</span> intercepts imports. The enabling point is the test setup. Link seams are powerful but fragile — they couple tests to implementation details like class names.',
     },
     {
       lead: 'Subclass seams',
-      text: 'work by extracting behavior into a protected method, then overriding it in a test subclass. This technique is underrated for legacy code because it requires minimal changes — you extract one line into a method, and suddenly you have a seam.',
+      text: 'Works by extracting behavior into a protected method, then overriding it in a test subclass. This technique is underrated for legacy code because it requires minimal changes — you extract one line into a method, and suddenly you have a seam.',
     },
     {
       lead: 'Preprocessor seams',
-      text: 'apply anywhere you use environment-based branching. Rails\' `Rails.env.test?`, Laravel\'s `app()->environment(\'testing\')`, and Node\'s `process.env.NODE_ENV === \'test\'` are all effectively preprocessor seams. Use them sparingly — they litter production code with test concerns.',
+      text: 'Applies anywhere you use environment-based branching. Rails\' <span class="font-mono">Rails.env.test?</span>, Laravel\'s <span class="font-mono">app()->environment(\'testing\')</span>, and Node\'s <span class="font-mono">process.env.NODE_ENV === \'test\'</span> are all effectively preprocessor seams. Use them sparingly — they litter production code with test concerns.',
     },
   ]}
 />
@@ -178,8 +180,6 @@ The workflow looks like this: First, identify the behavior you need to protect.
 
 With both in place, you can isolate and test without understanding the full system. The code is no longer untestable — it's testable through observation and substitution.
 
-This is the foundation. Deeper techniques — Extract and Override for quick dependency breaking, Parameterize Constructor for clean DI patterns, Strangler Fig for system-level migration — all build on characterization tests and seams. But start here. Get your first characterization test passing. Find your first seam. The rest follows.
-
 <Download
   resource="legacy-code-testing-characterization-tests-seams"
   title="Adding Tests to Untestable Legacy Code"
@@ -192,10 +192,12 @@ This is the foundation. Deeper techniques — Extract and Override for quick dep
   ]}
 />
 
+This is the foundation. Deeper techniques — Extract and Override for quick dependency breaking, Parameterize Constructor for clean DI patterns, Strangler Fig for system-level migration — all build on characterization tests and seams. But start here. Get your first characterization test passing. Find your first seam. The rest follows.
+
 ## Conclusion
 
 The myth of "untestable" code usually means "code that's hard to test with conventional techniques." Characterization tests and seams change the equation entirely — they let you observe, document, and isolate without first having to understand every line.
 
 Start with characterization tests. Run the code, capture what happens, lock it down. Don't judge whether the behavior is correct — just document it. Then find seams: the constructor parameters, the class methods, the environment flags that let you substitute behavior without editing the code you're protecting.
 
-These foundations enable everything else: dependency breaking, incremental extraction, system-level migration. But they're also sufficient on their own to turn "untestable" into testable. The question isn't __can__ you test legacy code — it's whether the investment is worth it for code that may never change.
+These foundations enable everything else: dependency breaking, incremental extraction, system-level migration. But they're also sufficient on their own to turn "untestable" into testable. The question isn't _can_ you test legacy code — it's whether the investment is worth it for code that may never change.