Verified, Not Trusted: Expense Analysis, Part One
Expense totals need verifiable source coverage and reproducible calculations. Two prompts show how parsing, category rules, refunds, and code shape the evidence.
Updated · Markdown
Software Engineering and Applied AI Engineering
Articles by Shiv Kumar on software architecture, programming, acceptance testing, and building with language models.
Latest articles
New and updated articles, most recent first.
Programming to Exceptions, Part 1: Method Contracts and Failure
Method contracts let callers rely on completed work and let failures propagate. C# examples distinguish retrieval from search, validate domain entry points, and assign handling to its owner.
Updated · Markdown
Programming to Exceptions, Part 2: Diagnostics and Boundaries
Specific exceptions preserve failure meaning, causes, and context. A shallow C# hierarchy, Gateway translation, and middleware enrichment carry diagnostic records across service boundaries.
Updated · Markdown
Programming to Exceptions, Part 3: Logging and Progress
Structured logs preserve the facts needed to investigate failures. Application Insights custom dimensions make them searchable, while typed progress events track long-running work.
Updated · Markdown
A Suite the Team Can Keep Trusting
A growing acceptance suite stays trustworthy through explicit scenarios and owned resources. Organize by feature, keep Act visible, review complete comparisons, and retain useful CI failures.
Updated · Markdown
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.
Updated · Markdown
Assertions That Verify the Whole Outcome
Assertions must compare every required field, count, and effect. Pure asserters separate observations from comparisons and report available failures together with verified expectations.
Updated · Markdown
From a Green Suite to a Release
A green behavioral suite supports release when its evidence belongs to the build being advanced. Preserve execution receipts and verify deployed capabilities, configuration, and other release duties.
Updated · Markdown
Functional Acceptance Testing at the Boundary
Functional acceptance tests verify complete outcomes through the assembled system. Correct arrangements, deep assertions, and controlled observations support release confidence.
Updated · Markdown
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.
Updated · Markdown
Knowing Which Scenarios a Feature Requires
A green suite needs correct scenarios for established requirements. An obligation map connects each rule to its arrangement, expected outcome, independent observation, and assertion.
Updated · Markdown
Learning a System Through Its Tests
Acceptance tests let teammates learn requirements and production behavior together. Follow one order through Arrange, the visible Act, independent observations, and complete assertions.
Updated · Markdown
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.
Updated · Markdown
Questions About Functional Acceptance Testing at the Boundary
Boundary testing questions concern evidence, isolation, failures, and release confidence. Compare the practice with mocks, TDD, generated checks, formal models, and production observation.
Updated · Markdown
Refactoring and Adopting Boundary Testing
A stable Domain Facade lets acceptance scenarios and assertions survive internal refactoring. Adapt test support behind unchanged observations and adopt complete boundary tests feature by feature.
Updated · Markdown
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.
Updated · Markdown
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.
Updated · Markdown
Testing the Service Interface
Interface tests verify wire conversion and exception translation at their owning boundaries. Controller Hooks, middleware checks, and hosted HTTP scenarios complement domain acceptance.
Updated · Markdown
The Regression Suite the Business Is Paying For
The maintained regression suite protects earlier business behavior as new features change the system. Keep approved expectations, run the required suite, and preserve lessons as permanent scenarios.
Updated · Markdown
The Test Mediator and the Transport Spy
A Test Mediator and transport spy control delivery and expose observations while production gateways run. Capture email content, script retries, and measure bounded response reads.
Updated · Markdown
Separate State from Behavior? Yes Please!
Business operations are easier to trace when immutable DTOs carry facts and stateless managers validate inputs and coordinate work through named methods at the call site.
Updated · Markdown
Factory Pattern: The Enabler of Polymorphism
A Factory selects and constructs a concrete descendant while callers program to an interface through the base class's public contract. C# thumbnailers show selection and polymorphic dispatch.
Updated · Markdown
The Configuration Provider: Roles and Responsibilities
A Configuration Provider hides the source and returns validated, typed settings. Useful exceptions and composed settings providers keep configuration rules in one place.
Updated · Markdown
The Gateway Design Pattern: Roles and Responsibilities
A Gateway presents business operations, translates service models and transforms failures into domain exceptions, keeping external service details behind one boundary.
Updated · Markdown
Factory Method Pattern: The Most Beautiful Pattern We Lost
Factory Method lets consumer subclasses choose dependencies through an overridable creation hook. C# examples show its two class families and distinguish it from a separate Factory.
Updated · Markdown
Stampede at the Gates
AI generation exposed an already flawed SDLC: faster code review moves the queue to verification, which needs functional acceptance testing at the boundary.
Updated · Markdown
The AI-Native Lifecycle
An AI-native SDLC engineers both gates through certified code review, functional acceptance tests at the boundary ratified by humans, and verification against the specification.
Updated · Markdown
Jev: A Practical Reference
Jev makes bounded semantic judgments with Choice, Score, and Noul; code handles exact work and policy, while evaluation and confidence gates determine when to act or escalate.
Using Jev Compact LLM Context
Jev can shorten LLM context by scoring which tool events a current question still needs. A recorded Noul response and Python retention code show what stays and why the threshold matters.
Prefer Composition Over Inheritance
Composition keeps a configuration provider's capabilities limited to what its project needs. The refactor uses self-contained settings providers, a shallow base, and restrained reuse.
Updated · Markdown
Always Use the "as" Operator? No Thank You!
Use a cast instead of `as` when the type is expected, so a mismatch raises InvalidCastException. Use `is` when the type genuinely varies and keep only guards backed by a real case.
Updated · Markdown
Validating Formal Arguments? No Thank You!
Validate and clean data at the front and back doors; skip checks on internal formal arguments. Immutable DTOs preserve trust, one exception reports all errors, and black box tests exercise the doors.
Updated · Markdown
Design Nugget: Evolution To Strategy
Build a working baseline, then change the design for a concrete benefit; a log parser evolves through a switch, delegates, and Strategy to test that judgment.
Updated · Markdown
C# 8 - Async Streams
Async streams let callers process database rows before the full result exists. An async iterator combines await and yield return, keeping its reader open during enumeration.
Updated · Markdown
Dependency Injection? No Thank You!
Dependency injection exposes private collaborators to callers when used for every internal relationship. Keep classes self-contained and let business code choose real variation.
Updated · Markdown
Interfaces? No Thank You!
C# interfaces do not inherently create contracts or loose coupling. Composition handles hierarchy conflicts; capability interfaces and structural typing let consumers see only what they need.
Updated · Markdown
Extension Methods? No Thank You!
Keep project-specific helpers as static methods: extension methods hide behavior behind namespaces and can change meaning with imports. Use them when they serve the wider C# community.
Updated · Markdown
Clean Abstractions Around Libraries
A library boundary owns the application's contract even when its terms match the library's. It contains provider types, validation, failures, and configuration, and keeps replacement possible.
Updated · Markdown
Intentional Model Design
A model should express required fields, genuine absence, and distinct variants in its type. Python unions and C# records encode those promises, while boundaries check external values.
Updated · Markdown
Async-Await in C#
Asynchronous I/O frees server threads during waits and can improve capacity under load. IIS request flow, Task.WhenAll, and load tests show where the benefit ends.
Updated · Markdown
Mocking? No Thank You!
Test whole features through the public surface so regression tests survive later design changes. Class mocks bind tests to internals; transport doubles cover rare external failures.
Updated · Markdown
Skills versus Controlled Workflows
When a useful answer is enough, and when you also have to demonstrate that a prescribed procedure was followed.
Updated · Markdown