Integration Testing: Practices, Challenges, and Practical Tips

Integration testing overview

Integration testing focuses on verifying that a single business module’s data‑exchange logic and functionality meet expectations when interacting with its upstream and downstream services.

Problem scenario

In a micro‑service e‑commerce system, the order service depends on user, product, inventory, coupon services and a database. The following Flask example illustrates a typical order‑creation flow with those dependencies:

from flask import Flask, request, jsonify

app = Flask(__name__)

# Assume these functions call user, inventory, coupon services
def get_user_info(user_id):
    pass

def get_product_info(product_id):
    pass

def apply_coupon(coupon_code, price):
    pass

@app.route('/api/orders', methods=['POST'])
def create_order():
    data = request.get_json()
    user_id = data['user_id']
    product_id = data['product_id']
    coupon_code = data.get('coupon_code', None)

    # fetch user and product info
    user_info = get_user_info(user_id)
    product_info = get_product_info(product_id)

    # calculate price
    price = product_info['price']

    # apply coupon if present
    if coupon_code:
        discount = apply_coupon(coupon_code, price)
    else:
        discount = 0

    # create order in DB
    order_id = create_order_in_database(user_id, product_id, price, discount, coupon_code)

    return jsonify({
        "order_id": order_id,
        "user_id": user_id,
        "product_id": product_id,
        "price": price,
        "discount": discount,
        "coupon_code": coupon_code
    })

def create_order_in_database(user_id, product_id, price, discount, coupon_code):
    # store order in database
    pass

if __name__ == '__main__':
    app.run()

Even when a tester is responsible only for the order module, they must consider the availability of upstream services (user, product, inventory, coupon) and downstream calls (database). Mocking unavailable services keeps tests running but only guarantees internal correctness, not overall system behavior.

The goal of integration testing is to ensure that the contract between the module and its dependent services is fulfilled. A contract typically covers:

Database schema design

Whether the application accesses the database directly or via a DAL/component pool

Request/response key‑value conventions

Encryption requirements and algorithms

Integration testing therefore solves two core problems:

Validate that the contract matches expectations.

Confirm that business requirements built on top of the contract are correctly implemented.

Interface testing is one method to verify contract implementation, but it is not the only approach; design‑phase test reviews can also assess contract feasibility.

Practical considerations

Test planning : create an integration‑test plan or flow guideline; a full document is optional but a standardized process is recommended.

Test methods : go beyond interface checks to include exception scenarios, fault injection, and baseline performance testing.

Test data : prepare mock data for upstream calls and seed the database with required entities (users, products, inventory, coupons).

Test cases : cover positive flows, reverse scenarios (refunds/cancellations), and boundary conditions (purchase limits, single‑use coupons).

Security validation : verify unauthenticated, unauthorized, and cross‑domain permission cases (e.g., regular users receiving VIP discounts).

Continuous integration : embed interface tests into the CI/CD pipeline to obtain rapid feedback on each change.