Why Self‑Testing Can’t Catch All Bugs Before SIT – A Backend Developer’s Reality

Yesterday at 10 p.m. in the office pantry, a colleague insisted that any bug not fixed during the developers' self‑testing phase becomes the developers' responsibility in SIT, to which I replied that expecting zero bugs is unrealistic unless we are omniscient AI.

In Java backend projects, many issues only appear in SIT because the local test data is clean while SIT uses real, messy user data, leading to duplicate phone numbers, missing fields, and database unique‑index violations.

System Integration Testing (SIT) combines all modules and external services—SMS, payment, risk control, third‑party APIs—so mocks used locally cannot replicate real data or inaccurate API contracts, causing format mismatches, timeouts, or crashes that self‑testing cannot anticipate.

Large systems also involve distributed components, caches, and message queues; local tests run single‑node, single‑threaded, but SIT may introduce high concurrency, exposing problems like overselling inventory due to race conditions.

@Transactional
public void reduceStock(Long productId, Integer count) {
    Product p = productRepository.findById(productId).orElseThrow(...);
    if (p.getStock() < count) {
        throw new RuntimeException("库存不足");
    }
    p.setStock(p.getStock() - count);
    productRepository.save(p);
}

In SIT, concurrent threads read the same stock before the transaction commits, causing overselling—an issue that cannot be discovered by simple self‑testing.

Additional SIT problems include network latency, long service chains, and cascading timeouts that lead to service avalanches, which a single developer cannot simulate without load testing.

While companies aim for zero bugs in SIT to avoid blame, developers can only catch about 80 % of low‑level bugs; the remaining 20 % stem from environment or integration issues that require team‑wide responsibility and post‑mortem analysis.

To truly reduce SIT bugs, sufficient time, realistic test environments, data, tools, and end‑to‑end automation are needed; otherwise, the pressure leads to a culture of blame and stifles innovation.