<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Software Engineering on Rough Edges</title><link>https://roughedges.dev/tags/software-engineering/</link><description>Recent content in Software Engineering on Rough Edges</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 15 Apr 2026 00:00:00 -0400</lastBuildDate><atom:link href="https://roughedges.dev/tags/software-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>Your Test Strategy Should Match Your Reality</title><link>https://roughedges.dev/posts/rethinking-your-test-strategy/</link><pubDate>Wed, 15 Apr 2026 00:00:00 -0400</pubDate><guid>https://roughedges.dev/posts/rethinking-your-test-strategy/</guid><description>&lt;p&gt;The critique of over-mocking in unit tests is worth taking seriously. It&amp;rsquo;s a real problem, and it&amp;rsquo;s more widespread than the industry generally acknowledges.&lt;/p&gt;
&lt;p&gt;When you mock every dependency in a unit test, you&amp;rsquo;re no longer testing whether your code works – you&amp;rsquo;re testing whether your code does what you told your mocks to pretend the dependencies do. If the mocks don&amp;rsquo;t reflect production behavior, your tests pass and your production system still breaks. Worse, those tests make your codebase rigid. Every internal refactor requires updating a web of mock expectations, which creates friction, which leads to tests being deleted rather than maintained, which defeats the purpose entirely.&lt;/p&gt;</description></item></channel></rss>