Eliminate Test Data Dependencies for More Robust Automation

In automated testing, the term "data‑driven" usually means driving test execution with external data. This article introduces a contrasting "no‑data‑driven" strategy that tries to remove data injection from test cases, placing most data maintenance outside the tests to reduce cost and increase robustness.

The goal of no‑data‑driven testing is to write test cases that require only a minimal amount of data, allowing them to run repeatedly without frequent maintenance.

An example is presented for a product‑sale API that uses a header with parameters gid and pid. The test verifies that a purchase adds a 30‑day validity period, reduces the user’s balance, and grants an additional 7‑day header.

/**
  * Purchase month‑card test case
  */
public void testDemo001() {
  String label = "购买月卡用例" + TAB + Thread.currentThread().getStackTrace()[1];
  Headgear headgear = new Headgear(base);
  Long aLong = headgear.getHeadgearInfo().get(27);
  int balance = NajmBase.getUserBalance(drive.user_id);
  long deadTime = drive.getDeadTime();
  Verify verify = new Verify(drive.bugMonthCard(gid, pid));
  int balance1 = NajmBase.getUserBalance(drive.user_id);
  long deadTime1 = drive.getDeadTime();
  Long aLong1 = headgear.getHeadgearInfo().get(27);
  JSONObject result = new JSONObject();
  result.put("状态码为0", verify.isRight());
  result.put("用户金额减少", balance - balance1 == 2000);
  result.put("用户月卡有效期增加", deadTime1 - deadTime == 30 * DAY);
  result.put("用户赠送头套正常", aLong1 - aLong == 7 * DAY);
  MySqlTest.saveTestResult(label, result);
}

The test flow is straightforward: retrieve the user’s header information (ID 27) to get the current expiration, fetch the user’s balance, perform the purchase via drive.bugMonthCard(gid, pid), then re‑query the balance and expiration to verify the expected changes.

All test cases require proper setup and teardown. The article outlines a maintenance plan for the data items involved:

Ensure that the gid and pid headers exist and that the test user has previously purchased a valid product.

Keep the price of the gid/pid product constant at 2000 and guarantee the user’s pre‑purchase balance exceeds this amount during setup.

Maintain a fixed 30‑day validity for the purchased header and a 7‑day bonus header (ID 27) with identical attributes.

Continuously track business changes to keep the test data in sync.

Designing and maintaining these parameters can be time‑consuming, but they can eventually be eliminated by fetching dynamic values from the header‑information API, removing the need for hard‑coded gid, pid, price, and fixed durations.

In practice, the author reports that the approach almost fully achieves the "write once, run everywhere" principle, with only rare exceptions caused by external factors.

Relevant repository links for the FunTester framework:

Gitee: https://gitee.com/fanapi/tester

GitHub: https://github.com/JunManYuanLong/FunTester