<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>CI/CD on API Coding</title>
    <link>https://apicoding.com/tags/ci/cd/</link>
    <description>Recent content in CI/CD on API Coding</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 17 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://apicoding.com/tags/ci/cd/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>API Testing Strategies: What to Test and When</title>
      <link>https://apicoding.com/api-testing-strategies-what-to-test-and-when/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://apicoding.com/api-testing-strategies-what-to-test-and-when/</guid>
      <description>&lt;p&gt;An API can pass every unit test in its suite and still break every client that calls it, because unit tests check that functions do what the code says they do, not that the API does what the contract says it does. That gap is where most production API incidents actually come from: a field renamed, a status code changed from 200 to 204, a required parameter quietly made optional. Testing an API well means testing at several different levels, because each one catches a different class of failure.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
