<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Bdd on Daffa Abhipraya</title><link>https://blog.abhipraya.dev/tags/bdd/</link><description>Recent content in Bdd on Daffa Abhipraya</description><generator>Hugo</generator><language>en-us</language><copyright>© Daffa Abhipraya</copyright><lastBuildDate>Fri, 24 Apr 2026 00:00:00 +0700</lastBuildDate><atom:link href="https://blog.abhipraya.dev/tags/bdd/index.xml" rel="self" type="application/rss+xml"/><item><title>PPL: Beyond Unit Tests with Load, BDD, SAST, and Schema Fuzzing</title><link>https://blog.abhipraya.dev/ppl/part-a/more-testing/</link><pubDate>Fri, 24 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-a/more-testing/</guid><description>&lt;p>The unit-vs-integration debate dominates testing conversations to the point that engineers forget there are entire categories of test that have nothing to do with either. A unit test that mocks the database does not tell you whether your endpoint survives 50 concurrent users. An integration test that asserts on database state does not catch a vulnerable transitive npm dependency. Both miss the question &amp;ldquo;does the API match its own published spec under arbitrary inputs?&amp;rdquo; In this blog I walk through four &amp;ldquo;other&amp;rdquo; testing dimensions we wired into a FastAPI + React monorepo, each filling a gap unit/integration testing structurally cannot.&lt;/p></description></item></channel></rss>