<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Testing on dplabs — Software Engineering &amp; Technology Consultancy</title>
		<link>https://dplabs.tech/tags/testing/</link>
		<description>Recent content in Testing on dplabs — Software Engineering &amp; Technology Consultancy</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Mon, 01 Jun 2026 00:00:00 +0000</lastBuildDate>
		
			<atom:link href="https://dplabs.tech/tags/testing/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Infrastructure as Code Is Software</title>
				<link>https://dplabs.tech/blog/infrastructure-as-code-is-software/</link>
				<pubDate>Mon, 01 Jun 2026 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/infrastructure-as-code-is-software/</guid>
				<description>&lt;p&gt;Infrastructure as Code emerged as a response to the problem of undocumented, inconsistent, manually-managed infrastructure. Click-ops servers where nobody knows what&amp;rsquo;s actually configured. Snowflake environments that differ from production in undocumented ways. Infrastructure that can&amp;rsquo;t be reproduced.&lt;/p&gt;&#xA;&lt;p&gt;IaC solved these problems by treating infrastructure as code. The irony is that many teams write infrastructure code with none of the engineering rigor they apply to application code. No reviews, no tests, no code quality standards, no documentation. The result: IaC that has the same problems as the click-ops it replaced, plus the added complexity of Terraform state files.&lt;/p&gt;</description>
			</item>
			<item>
				<title>AI Engineering Is Software Engineering</title>
				<link>https://dplabs.tech/blog/ai-engineering-is-software-engineering/</link>
				<pubDate>Mon, 09 Mar 2026 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/ai-engineering-is-software-engineering/</guid>
				<description>&lt;p&gt;There&amp;rsquo;s a tendency to treat AI features as different from other software. Different enough that normal engineering practices don&amp;rsquo;t apply, or apply differently, or can be deferred. This tendency produces AI systems that are unreliable, unobservable, expensive to operate, and difficult to improve.&lt;/p&gt;&#xA;&lt;p&gt;AI systems built with the same engineering discipline as other distributed systems are more reliable, cheaper to operate, and easier to improve. The disciplines aren&amp;rsquo;t different. The application is.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Evaluating LLM Applications: Beyond Vibe Checks</title>
				<link>https://dplabs.tech/blog/evaluating-llm-applications/</link>
				<pubDate>Mon, 26 Jan 2026 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/evaluating-llm-applications/</guid>
				<description>&lt;p&gt;Most teams evaluate their LLM applications by asking them a few questions and deciding whether the answers look right. This is not evaluation — it&amp;rsquo;s a vibe check. It doesn&amp;rsquo;t scale, doesn&amp;rsquo;t catch regressions, and doesn&amp;rsquo;t provide any basis for measuring improvement over time.&lt;/p&gt;&#xA;&lt;p&gt;Systematic LLM evaluation is harder than evaluating deterministic software. The outputs are probabilistic, quality is multidimensional, and the correct answer often isn&amp;rsquo;t a single string. These are difficulties, not reasons to skip evaluation.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Spring Boot Dependency Injection Without Losing Your Architecture</title>
				<link>https://dplabs.tech/blog/spring-boot-dependency-injection/</link>
				<pubDate>Mon, 21 Jul 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/spring-boot-dependency-injection/</guid>
				<description>&lt;p&gt;Spring&amp;rsquo;s dependency injection container is one of the most mature and capable DI frameworks available. It&amp;rsquo;s also capable of enabling architectures that are deeply coupled to Spring internals, impossible to test without a full Spring context, and opaque about their dependencies.&lt;/p&gt;&#xA;&lt;p&gt;The patterns that produce good Spring Boot architectures are not complicated. They require deliberate choices about when to use Spring and when to step back from it.&lt;/p&gt;&#xA;&lt;h2 id=&#34;constructor-injection-is-non-negotiable&#34;&gt;Constructor Injection Is Non-Negotiable&lt;/h2&gt;&#xA;&lt;p&gt;Spring supports three injection mechanisms: constructor, setter, and field injection. Field injection (&lt;code&gt;@Autowired&lt;/code&gt; on a field) is the most common and the worst.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Spring Boot Testing: What Should Actually Be Tested and How</title>
				<link>https://dplabs.tech/blog/spring-boot-testing-strategy/</link>
				<pubDate>Mon, 10 Feb 2025 00:00:00 +0000</pubDate>
				<guid>https://dplabs.tech/blog/spring-boot-testing-strategy/</guid>
				<description>&lt;p&gt;Spring Boot&amp;rsquo;s testing support is extensive and well-designed. It&amp;rsquo;s also easy to misuse in ways that produce slow, fragile test suites with poor diagnostic value.&lt;/p&gt;&#xA;&lt;p&gt;The core question is not &amp;ldquo;how do I test with Spring Boot?&amp;rdquo; but &amp;ldquo;what needs to be tested, and at what level?&amp;rdquo;&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-testing-pyramid-applied-to-spring-boot&#34;&gt;The Testing Pyramid Applied to Spring Boot&lt;/h2&gt;&#xA;&lt;p&gt;The testing pyramid principle: favor many fast, isolated unit tests over fewer slow integration tests. Each level of the pyramid is slower and more expensive to run but tests more of the system.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
