Writing
Arranging Scenarios That Stay True
Random data must preserve the named test scenario. Constrained catalog sampling, immutable builders, deliberate threshold guards, and owned identities keep arrangements correct.
Topic
Data Access
Reaching a store without letting its shape leak upward. Language-independent guidance, currently illustrated in Python.
11 pages
Writing
Idempotency and Concurrent Requests
Repeated and concurrent order requests must preserve accepted outcomes without duplicate work. Compare canonical request identity, allowed race outcomes, stored facts, and outgoing effects.
Writing
One Order, Every Obligation
One ordering scenario verifies the caller result, stored lines, fulfillment, and confirmation. Follow its complete C# test, independent observations, and accumulated failure reports.
Writing
Refusals, Failures, and Work Still Owed
Failure timing determines what an order still owes. Verify refusal, real transaction rollback, post-commit action failures, and accepted effects whose completion could not be recorded.
Writing
Testing Against Real Infrastructure
Real infrastructure must participate when transactions and messages are required outcomes. Provision SQL and broker topology, isolate runs, define observation windows, and verify actual rollback.
Writing
SOLID IS OLD: Dependency Inversion Needs a Good Abstraction
Dependency inversion needs domain-owned contracts that hide implementation knowledge. Follow a show query from source dependencies through models to a stored procedure.
Writing
Abstraction in Software Design
Useful abstractions express the caller's needs precisely. Broker, database and charting examples show where SDK types, storage details and excess generality get in the way.
Chapter
LINQ and Query Semantics in C#
A query does not run when you write it, and calling it twice may not give the same answer. Deferred execution, materialization, terminal operators, and untranslatable queries.
Writing
Data Access Layer CodeGen
Stored-procedure metadata drives ADO.NET code generation and typed DbDataReader wrappers, supporting streamed results or materialized lists according to how callers use the data.
Writing
The Purpose and function of a Data Access Layer
A Data Access Layer isolates business logic from the logical data model through domain-specific methods, stored procedures, and results shaped for the business layer.
Writing
DataReader Wrappers - TypeSafe
Typed DbDataReader wrappers centralize field access and null handling. Examples compare reusing one wrapper through IEnumerable<T> with creating objects for a List<T>.