<?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 PG Blog</title><link>https://pg-blogs.netlify.app/tags/testing/</link><description>Recent content in Testing on PG Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 03 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://pg-blogs.netlify.app/tags/testing/index.xml" rel="self" type="application/rss+xml"/><item><title>Testing Best Practices in Java</title><link>https://pg-blogs.netlify.app/posts/16-testing-best-practices-in-java/</link><pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate><guid>https://pg-blogs.netlify.app/posts/16-testing-best-practices-in-java/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Most Java codebases have plenty of tests and still get burned by production bugs. The problem is rarely &lt;em&gt;quantity&lt;/em&gt; — it&amp;rsquo;s that the tests exercise the wrong things: they assert internal wiring instead of behavior, they mock away every collaborator until nothing real is left, or they cover the happy path ten times and the failure path zero times.&lt;/p&gt;
&lt;p&gt;Good tests are fast, deterministic, and tell you something true about behavior. This post covers the practices that make JUnit 5 and Mockito tests actually earn their keep.&lt;/p&gt;</description></item><item><title>Testing Best Practices in Python</title><link>https://pg-blogs.netlify.app/posts/17-testing-best-practices-in-python/</link><pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate><guid>https://pg-blogs.netlify.app/posts/17-testing-best-practices-in-python/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Python&amp;rsquo;s testing tools are lightweight enough that it&amp;rsquo;s easy to write a lot of tests without writing &lt;em&gt;good&lt;/em&gt; ones. A suite that mocks every collaborator, duplicates the same assertion ten times with different inputs pasted in by hand, or chases a coverage number will pass in CI and still miss real bugs.&lt;/p&gt;
&lt;p&gt;pytest gives you fixtures, &lt;code&gt;parametrize&lt;/code&gt;, and &lt;code&gt;monkeypatch&lt;/code&gt; — the tools that make it just as easy to write the &lt;em&gt;right&lt;/em&gt; tests as the wrong ones. This post covers how to use them well.&lt;/p&gt;</description></item></channel></rss>