تست خودکار, تست نرم افزار

مجازی‌سازی سرویس با WireMock؛ تست خطا و وابستگی HTTP

انتشار در تاریخ توسط محمد عسکری

در تست پرداخت، پاسخ موفق PSP ساده‌ترین حالت است؛ ریسک واقعی وقتی ظاهر می‌شود که درخواست اول ۴۲۹ بگیرد، پاسخ دوم دیر برسد، connection وسط body قطع شود یا callback دوباره ارسال شود. سرویس واقعی معمولاً این حالت‌ها را هر زمان که QA بخواهد تولید نمی‌کند. مجازی‌سازی سرویس با WireMock این dependency را کنترل‌پذیر می‌کند—اما اگر مدل شبیه‌سازی از واقعیت drift کند، suite سبز می‌تواند اعتماد کاذب بسازد.

این راهنما از تعریف Service Virtualization عبور می‌کند و یک روش عملی می‌دهد: ریسک dependency را به رفتار نسخه‌دار، state قطعی، fault/latency کنترل‌شده، request evidence، reset و calibration تبدیل کنیم. نمونه‌ها بر شاخه پایدار WireMock ۳ و JUnit ۵ هستند؛ مستندات فعلی WireMock، نسخه ۴ را هنوز Beta معرفی می‌کنند.

مجازی‌سازی سرویس چیست؟

Service Virtualization یک dependency شبکه را با یک سرویس قابل‌کنترل جایگزین می‌کند تا برنامه تحت تست از همان protocol و boundary عمومی با آن تعامل کند. این سرویس می‌تواند response، state transition، delay، fault و request history تولید کند؛ بدون اینکه Provider واقعی آماده، پایدار، ارزان یا قابل‌وادارکردن به حالت خطا باشد.

راهنمای رسمی Service Virtualization در WireMock حالت standalone و پوشه‌های mappings/ و __files/ را معرفی می‌کند. WireMock عمدتاً برای protocolهای HTTPمحور مناسب است؛ شبیه‌ساز database، queue یا رفتار کامل کسب‌وکار نیست مگر با ابزار/extension و مدل جدا.

Stub، Mock، Fake و Virtual Service چه تفاوتی دارند؟

Test Double نقش غالب مثال
Dummy فقط پرکردن پارامتر؛ رفتار مهم ندارد شناسه‌ای که در سناریو استفاده نمی‌شود
Stub پاسخ از پیش‌تعریف‌شده برای ورودی GET کاربر → ۲۰۰ JSON
Mock انتظار interaction و verification POST دقیقاً دو بار با header مشخص
Fake پیاده‌سازی سبک اما کارا پرداخت درون‌حافظه‌ای با state
Virtual Service مدل شبکه‌ای قابل‌اشتراک از چند رفتار dependency PSP با success، ۴۲۹، timeout، callback و fault
Proxy/Recorder عبور یا ثبت ترافیک سرویس واقعی ضبط sandbox برای شروع مدل

مرزها مطلق نیستند؛ WireMock هم Stub می‌سازد، هم request را verify می‌کند و هم می‌تواند یک Virtual Service stateful باشد. مهم این است که در Test Plan بنویسید کدام ادعا را از آن انتظار دارید.

چه زمانی Service Virtualization انتخاب خوبی است؟

  • Provider هنوز ساخته نشده یا در CI در دسترس نیست؛
  • API شخص ثالث هزینه، quota یا محدودیت جغرافیایی دارد؛
  • تولید ۴۲۹، ۵۰۰، delay، malformed response یا disconnect در سرویس واقعی دشوار است؛
  • تست‌های موازی به state و داده مستقل نیاز دارند؛
  • می‌خواهید retry، timeout، circuit breaker و fallback را قطعی بسنجید؛
  • شبکه ایران، DNS، تحریم یا ناپایداری sandbox بازخورد PR را غیرقابل‌اتکا کرده است؛
  • Frontend/Consumer پیش از آماده‌شدن Provider باید توسعه یابد.

چه زمانی انتخاب بدی است؟

  • خود protocol واقعی، TLS/mTLS، proxy، DNS یا certificate محل ریسک است؛
  • هدف، ظرفیت و performance واقعی Provider است؛
  • رفتار آن‌قدر پیچیده شده که Virtual Service یک محصول دوم و ناسازگار می‌سازد؛
  • Contract یا مستند معتبر ندارید و فقط حدس تیم را encode می‌کنید؛
  • تست باید transaction واقعی database یا delivery semantics queue را ببیند؛
  • Recorder قرار است بدون مجوز روی traffic واقعی و داده شخصی اجرا شود؛
  • یک Stub همیشه-۲۰۰ قرار است جای همه Integration/E2Eها را بگیرد.

در این حالت‌ها از Provider محلی، Testcontainer، sandbox، Contract Test، E2E یا Probe استفاده کنید. راهنمای تست یکپارچه‌سازی به انتخاب Narrow/Broad و dependency واقعی کمک می‌کند.

نردبان Fidelity؛ WireMock کجای سبد قرار می‌گیرد؟

  1. Pure/Unit: بدون HTTP؛ منطق تصمیم با object double؛
  2. HTTP Virtual Service: client واقعی در برابر WireMock و faultهای قطعی؛
  3. Contract-calibrated Virtual Service: mappingها با Contract/Provider verification سنجیده می‌شوند؛
  4. Provider Integration/Sandbox: protocol و رفتار Provider واقعی در محیط کنترل‌شده؛
  5. Deployed E2E/Probe: routing، config، TLS و ترکیب واقعی منتخب.

هر پله سؤال متفاوتی پاسخ می‌دهد. هدف بالا رفتن همه تست‌ها نیست؛ edge caseها در پله ارزان و چند خطر fidelity در پله‌های بالاتر می‌مانند. برای مرز CDC و مسیر deployشده، مقاله CDC در مقابل E2E را ببینید.

مدل رفتاری را پیش از WireMock بنویسید

هر Virtual Service باید یک Manifest قابل‌بازبینی داشته باشد:

فیلد پرسش نمونه PSP
Risk/Scenario کدام رفتار Consumer را می‌سنجیم؟ retry یک‌باره پس از ۴۲۹
Request contract کدام method/path/header/body مهم است؟ POST verify + Idempotency-Key + amountRial
Response sequence چه state و ترتیبی لازم است؟ ۴۲۹ سپس ۲۰۰
Fault/Latency کدام شکست و budget؟ delay بیشتر از client timeout
Oracle رفتار درست Consumer چیست؟ حداکثر یک retry و یک اثر مالی
Reset/Isolation state چگونه مستقل می‌شود؟ server per test یا scenario/run ID
Source/Version مدل از کجا و برای کدام نسخه است؟ PSP spec v3 + calibration date
Owner/Expiry چه کسی drift را اصلاح می‌کند؟ Payments team؛ بازبینی ماهانه
Data safety چه چیزی ممنوع یا redact است؟ بدون PAN/token/شماره همراه واقعی

این Manifest می‌تواند کنار mappingها یا در metadata/README نگه‌داری شود. بدون intent و owner، پوشه JSON به‌سرعت به قبرستان Stub تبدیل می‌شود.

نصب WireMock ۳ و JUnit ۵

صفحه رسمی نصب WireMock در زمان نگارش، ۳.۱۳.۲ را نسخه پایدار ۳.x و ۴.x را Beta معرفی می‌کند. نسخه را در dependency catalog/lockfile تثبیت و ارتقا را در CI آزمایش کنید:

<dependency>
  <groupId>org.wiremock</groupId>
  <artifactId>wiremock</artifactId>
  <version>3.13.2</version>
  <scope>test</scope>
</dependency>

Extension رسمی JUnit Jupiter با @WireMockTest یک server روی پورت تصادفی اجرا می‌کند و mapping/requestها را پیش از هر test method reset می‌کند. پورت تصادفی از collision اجرای موازی جلوگیری می‌کند.

Request Matching؛ به‌اندازه ریسک دقیق باشید

WireMock می‌تواند URL، method، query، form، header، cookie، body، multipart و client IP را match کند. مرجع Request Matching operatorهای JSON/XML/JSONPath/XPath و date-time را پوشش می‌دهد.

Under-matching

اگر فقط path را match کنید، درخواست با method، واحد پول یا auth اشتباه هم همان پاسخ را می‌گیرد. تست سبز می‌شود، درحالی‌که Provider واقعی رد می‌کند.

Over-matching

اگر token، timestamp یا ترتیب بی‌اهمیت JSON را exact کنید، mapping با هر اجرای معتبر می‌شکند. فیلدهای semantic را دقیق و فیلدهای متغیر را با pattern/type مناسب بسنجید.

قاعده عملی

  • method و path عمومی را دقیق کنید؛
  • headerهای contract/security مهم را match کنید؛
  • body را بر فیلدهای مصرف‌شده و واحد/enum حساس کنید؛
  • request ID و timestamp را pattern کنید؛
  • unknown/unmatched request را failure قابل‌مشاهده نگه دارید.

مثال عملی: PSP ابتدا ۴۲۹، سپس ۲۰۰

نمونه زیر از client واقعی پروژه استفاده می‌کند، state را با Scenario کنترل می‌کند و interaction را verify می‌کند:

import static com.github.tomakehurst.wiremock.client.WireMock.*;
import static com.github.tomakehurst.wiremock.stubbing.Scenario.STARTED;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;

import com.github.tomakehurst.wiremock.client.MappingBuilder;
import com.github.tomakehurst.wiremock.junit5.WireMockRuntimeInfo;
import com.github.tomakehurst.wiremock.junit5.WireMockTest;
import org.junit.jupiter.api.Test;

@WireMockTest(failOnUnmatchedRequests = true)
class PaymentClientTest {

  @Test
  void retries_once_after_429(WireMockRuntimeInfo wm) {
    stubFor(verifyRequest().inScenario("rate-limit-once")
      .whenScenarioStateIs(STARTED)
      .willReturn(aResponse()
        .withStatus(429)
        .withHeader("Retry-After", "0"))
      .willSetStateTo("second-attempt"));

    stubFor(verifyRequest().inScenario("rate-limit-once")
      .whenScenarioStateIs("second-attempt")
      .willReturn(okJson("""
        {"verified":true,"referenceId":"TEST-REF-42"}
      """)));

    var client = new PaymentClient(wm.getHttpBaseUrl());
    var result = client.verify(1_250_000, "IRR", "run-8f5a-42");

    assertTrue(result.verified());
    assertEquals("TEST-REF-42", result.referenceId());
    verify(2, postRequestedFor(urlPathEqualTo("/v1/payments/verify")));
  }

  private static MappingBuilder verifyRequest() {
    return post(urlPathEqualTo("/v1/payments/verify"))
      .withHeader("Idempotency-Key", matching("run-[0-9a-f-]+"))
      .withRequestBody(equalToJson("""
        {"amountRial":1250000,"currency":"IRR"}
      """, true, false));
  }
}

PaymentClient در این مثال همان adapter تولید است، نه client مخصوص تست. verify(2,…) فقط تعداد request را ثابت می‌کند؛ یکتایی اثر مالی باید در Component/DB test با Oracle مستقل سنجیده شود.

Stateful Behaviour؛ ماشین حالت کوچک، نه Provider دوم

Scenario در WireMock از state شروع Started به stateهای بعدی می‌رود. موارد مناسب:

  • ۴۲۹ سپس success برای retry؛
  • status Pending سپس Paid برای polling؛
  • اولین token معتبر و سپس expired؛
  • یک resource قبل و بعد از update.

اگر ده‌ها entity، transaction و قانون دامنه را در Scenario بازسازی می‌کنید، مدل بیش‌ازحد بزرگ شده است. Fake هدفمند یا Provider واقعی شاید مناسب‌تر باشد.

خطر state مشترک در تست موازی

Scenario state متعلق به instance WireMock است. دو تست موازی روی یک scenario name می‌توانند ترتیب هم را عوض کنند. گزینه امن: instance جدا برای test/class، dynamic port، scenario name شامل run ID، یا serial execution آگاهانه. Reset باید بخشی از fixture باشد، نه دستور دستی فراموش‌شدنی.

Fault و Latency را با Oracle طراحی کنید

راهنمای Simulating Faults delay ثابت/تصادفی، chunked dribble و responseهای خراب مانند connection reset را ارائه می‌کند. فقط fault نسازید؛ انتظار سیستم را هم بنویسید:

Fault Oracle Consumer Evidence
429 + Retry-After retry محدود و رعایت policy attempt count و timestamp
500 عدم retry برای side effect غیرایمن یا policy صریح request/body/idempotency key
delay بالاتر از timeout cancel، fallback یا status نامعلوم client timeout و state نهایی
connection reset تفکیک نتیجه unknown از definite failure exception class و reconciliation job
malformed JSON خطای parsing کنترل‌شده، بدون log حساس reason code و redacted payload
body chunked کند read timeout و آزادسازی resource duration و connection pool

delay WireMock برای تست timeout/resilience مناسب است، نه اندازه‌گیری ظرفیت واقعی dependency. طراحی workload و SLO در مقاله برنامه تست عملکرد توضیح داده شده است.

Request Journal و Verification؛ interaction را شاهد کنید

WireMock requestهای دریافت‌شده را در Journal ثبت می‌کند و امکان count/match/near-miss/unmatched inspection می‌دهد. مرجع Verifying verification بر اساس همان matcherهای stubbing را نشان می‌دهد.

کاربردهای سالم:

  • assert اینکه retry از حد عبور نکرد؛
  • اثبات ارسال idempotency/correlation header؛
  • اثبات عدم فراخوانی PSP پس از validation محلی ناموفق؛
  • تشخیص body/path/header نزدیک به mapping اما نامنطبق؛
  • ذخیره unmatched summary در Evidence Pack.

Verification نباید implementation call graph را بی‌دلیل قفل کند. ابتدا outcome را assert کنید و فقط interactionی را verify کنید که بخشی از قرارداد یا safety property است.

Record/Playback نقطه شروع است، نه منبع حقیقت

Recorder رسمی WireMock می‌تواند از traffic proxied mapping بسازد. قبل از commit:

  1. مجوز ثبت و منبع traffic را مشخص کنید؛
  2. Authorization، Cookie، token، PAN، CVV، شماره همراه، کد ملی و PII را حذف کنید؛
  3. response و request را به مثال مصنوعی کمینه تبدیل کنید؛
  4. matcherهای بیش‌ازحد آزاد Recorder را بازبینی کنید؛
  5. timestamp، ID و داده ناپایدار را semantic pattern کنید؛
  6. رفتار ضبط‌شده را با Contract و نیاز کسب‌وکار تأیید کنید؛
  7. مالک، نسخه و تاریخ calibration بگذارید.

Snapshot ممکن است باگ Provider، داده شخصی یا پاسخ اتفاقی را منجمد کند. «واقعاً دیده شده» مساوی «رفتار صحیح و پایدار» نیست.

Proxying؛ fallback پنهان را ممنوع کنید

WireMock Proxying اجازه می‌دهد requestهای مشخص به سرویس واقعی عبور کنند. خطر اصلی این است که unmatched request بی‌صدا از شبکه خارج شود و تست بسته به internet، quota یا production data پاس کند.

  • target allowlist و egress policy داشته باشید؛
  • production را target پیش‌فرض نکنید؛
  • credential مصنوعی و حداقل دسترسی استفاده کنید؛
  • proxy fallback را در CI deterministic خاموش کنید؛
  • عبور هر request را log و artifact کنید؛
  • برای record، زمان، scope و retention محدود بگذارید.

Contract و Virtual Service مکمل‌اند

OpenAPI یا Pact می‌پرسد «آیا interaction سازگار است؟» WireMock می‌پرسد «Consumer در برابر این رفتار کنترل‌شده چه می‌کند؟» یک mapping WireMock به‌خودی‌خود Contract نیست و Stub نوشته‌شده توسط همان تیم Consumer ممکن است همان برداشت غلط را دو بار تکرار کند.

کالیبراسیون پیشنهادی:

  • request/response shape را با Contract/schema validate کنید؛
  • CDC را در Provider واقعی verify کنید؛
  • چند mapping پرریسک را دوره‌ای با sandbox مقایسه کنید؛
  • change Provider webhook/PR باید مالک mapping را مطلع کند؛
  • unknown field، enum و error جدید به drift report برسد.

برای چرخه واقعی Consumer→Provider→Broker→can-i-deploy به راهنمای Pact و تست قراردادی API مراجعه کنید.

ماتریس مجازی‌سازی درگاه پرداخت ایرانی

Scenario WireMock behavior Oracle سیستم تحت تست
Success ۲۰۰ با referenceId مصنوعی ثبت Paid و یک ledger effect
واحد اشتباه ۴۰۰ اگر currency≠IRR یا amountRial نامعتبر خطای domain و عدم retry
رقم فارسی در ورودی بالادست فقط canonical integer دریافت شود normalization پیش از adapter
Rate limit ۴۲۹ سپس ۲۰۰ retry محدود با همان idempotency key
Timeout پس از commit delay/reset با نتیجه نامعلوم عدم برداشت دوم؛ reconciliation
Duplicate verify ۴۰۹ یا همان نتیجه قبلی بر اساس spec outcome idempotent
Malformed response ۲۰۰ با JSON ناقص/خراب Parsing failure کنترل‌شده و redacted
Auth expired ۴۰۱ سپس token refresh path حداکثر یک refresh و بدون loop
Outage 503/connection reset circuit policy و degraded state روشن
Callback دیرهنگام سناریوی جدا/وبهوک کنترل‌شده Tehran/UTC و state transition معتبر

WireMock پاسخ PSP را کنترل می‌کند؛ یکتایی ledger، transaction دیتابیس و callback concurrency را باید در boundary گسترده‌تر آزمود. برای تبدیل این نیازها به Testability Contract از مقاله تست‌پذیری نرم‌افزار استفاده کنید.

داده، Privacy و امنیت Mappingها

  • فقط داده مصنوعی؛ PAN، CVV، token و PII واقعی ممنوع؛
  • مثال‌های response کمینه و غیرقابل‌انتساب باشند؛
  • secret در mapping، image، log یا Git ذخیره نشود؛
  • Admin API در شبکه عمومی expose نشود؛
  • mapping PR از نظر تغییر رفتار و نشت داده review شود؛
  • Artifact شکست، request body را با policy redact کند؛
  • recordings retention کوتاه و دسترسی auditشده داشته باشند.

identity، seed، reset و retention داده فارسی/پرداخت در راهنمای مدیریت داده تست به‌تفصیل آمده است.

WireMock در Docker و CI

تصویر رسمی Docker WireMock mappingها را از /home/wiremock/mappings و bodyها را از /home/wiremock/__files می‌خواند. برای CI:

  • نسخه image را pin و در محیط حساس digest تأییدشده استفاده کنید؛
  • پورت public منتشر نکنید؛ application از service DNS شبکه داخلی استفاده کند؛
  • mappingها read-only و versioned باشند؛
  • readiness واقعی WireMock و mapping load را بسنجید؛ sleep ثابت نگذارید؛
  • هر job project/namespace مستقل داشته باشد؛
  • unmatched requests، request journal خلاصه‌شده و logs قبل از teardown ذخیره شوند؛
  • Admin API فقط از runner مجاز قابل‌دسترسی باشد؛
  • cleanup محدود به project همان job باشد.

برای لَب Docker Compose، Evidence Pack و failure injection ایمن، راهنمای داکر برای عیب‌یابی تست و برای Artifact/Runner امن، تست در GitLab CI را ببینید.

راهنمای عیب‌یابی WireMock

نشانه بررسی اقدام
۴۰۴ از WireMock unmatched/near-miss، method/path/query diff matcher؛ mapping catch-all نسازید
Stub اشتباه پاسخ می‌دهد priority و overlap mappingها matcherها را تفکیک و fallback را پایین‌تر کنید
تست تنها در parallel می‌شکند port، scenario state و request journal مشترک instance/run namespace مستقل
retry بیش از انتظار Journal، Retry-After و client policy attempt/timing را assert و loop را محدود کنید
Local سبز، sandbox قرمز contract/version، header، auth، TLS، error semantics drift calibration و adapter integration
CI نمی‌تواند وصل شود service DNS، bind/port، readiness، network localhost را با service name جایگزین کنید
Mapping ضبط‌شده flaky است ID/time/token و matcher خودکار مثال مصنوعی و semantic pattern
Fault روی Windows متفاوت است نوع fault و محدودیت platform delay/HTTP error جایگزین و platform matrix
Memory بالا می‌رود Request Journal و suite طولانی instance scope/reset و retention مناسب
همه requestها پاس می‌شوند catch-all/proxy fallback fail-on-unmatched و deny-by-default

معیارهای سلامت Virtual Service

  • Risk-scenario coverage: failure modeهای اولویت‌دار با Oracle، نه تعداد mapping؛
  • Unmatched request rate: requestهای بدون مدل به تفکیک Consumer/version؛
  • Ambiguous match count: mappingهای هم‌پوشان یا catch-all؛
  • Calibration age: زمان از آخرین Contract/Provider/Sandbox comparison؛
  • Drift defects: اختلاف مدل با Provider و زمان اصلاح؛
  • False-confidence escapes: تست سبز WireMock و شکست interaction واقعی؛
  • Setup p50/p95: زمان آماده‌شدن Virtual Service و state؛
  • Reset reliability: درصد اجراهای بدون state/request باقی‌مانده؛
  • Failure actionability: failureهای دارای matcher diff، owner و اقدام؛
  • Mapping change amplification: تغییر Provider چند mapping/suite را دست‌کاری می‌کند؟
  • Sensitive-data violations: باید صفر و gateشونده باشد؛
  • Fidelity-ladder coverage: ریسک‌های اصلی در کدام پله شواهد واقعی دارند؟

برنامه ۳۰روزه پیاده‌سازی

هفته اول: یک dependency و پنج failure mode

PSP/SMS/Map پرریسک را انتخاب کنید؛ Contract، owner، داده ممنوع و پنج رفتار success/error/timeout را در Manifest ثبت کنید.

هفته دوم: JUnit و Evidence

WireMock ۳ با dynamic port، fail-on-unmatched، client واقعی، Request Verification و reset خودکار بسازید. یک Scenario stateful و یک malformed response اضافه کنید.

هفته سوم: Contract و Calibration

mappingها را با Contract/Provider verify کنید؛ یک sandbox comparison مجاز بسازید؛ drift report، owner و expiry تعریف کنید. ضبط خام را sanitize یا حذف کنید.

هفته چهارم: CI و Fidelity

image/version را pin، شبکه و داده را ایزوله و Journal/log را artifact کنید. حداقل یک Provider/Sandbox و یک E2E/Probe برای شکاف‌های HTTP/TLS/deployment نگه دارید؛ معیارهای قبل/بعد را ثبت کنید.

ضدالگوهای رایج

  • Stub همیشه-۲۰۰ برای dependency پرریسک؛
  • کپی response production با PII داخل Git؛
  • match فقط روی URL و نادیده‌گرفتن method/header/body مهم؛
  • exact کردن timestamp/token و ساخت flakiness مصنوعی؛
  • catch-all mapping یا proxy fallback پنهان؛
  • نوشتن client مخصوص تست به‌جای اجرای adapter واقعی؛
  • Scenario state مشترک در parallel؛
  • verify کردن callهای implementation به‌جای outcome/contract؛
  • استفاده از delay WireMock به‌عنوان Performance Test؛
  • فرض اینکه mapping همان Contract یا رفتار واقعی Provider است؛
  • مدل‌کردن کل منطق Provider در WireMock؛
  • Record/Playback بدون review، redact و calibration؛
  • Admin API عمومی یا credential واقعی در simulator؛
  • mutable latest image و mapping بدون version/owner؛
  • حذف sandbox/E2E قبل از اثبات fidelity ladder.

چک‌لیست نهایی Service Virtualization

  • ریسک، Contract، Source version، owner و expiry ثبت شده‌اند.
  • WireMock روی شاخه پایدار pin شده و ارتقا در CI آزموده می‌شود.
  • client/adapter production از base URL تزریقی استفاده می‌کند.
  • method/path/header/body به‌اندازه ریسک match می‌شوند.
  • unmatched request failure و near-miss evidence روشن است.
  • success، error، rate-limit، timeout و malformed response Oracle دارند.
  • Scenario، port، data و Journal میان اجراها ایزوله/reset می‌شوند.
  • Contract/Provider/Sandbox drift دوره‌ای سنجیده می‌شود.
  • Recorder/Proxy deny-by-default، مجاز، redactشده و auditشونده است.
  • هیچ PII/secret واقعی در mapping، log یا artifact نیست.
  • Docker image/mapping pin و Admin API شبکه‌محدود است.
  • Provider Integration و E2E/Probe برای شکاف fidelity حفظ شده‌اند.

پرسش‌های متداول WireMock و مجازی‌سازی سرویس

WireMock جای Pact را می‌گیرد؟

خیر. WireMock رفتار HTTP کنترل‌شده می‌سازد؛ Pact انتظار Consumer را به Provider واقعی verify و سازگاری نسخه‌ها را مدیریت می‌کند. می‌توان mapping WireMock را با Contract کالیبره کرد.

WireMock جای Integration Test با سرویس واقعی را می‌گیرد؟

فقط برای ریسک‌هایی که در client behavior و protocol مدل‌شده‌اند. TLS، config، رفتار واقعی Provider و drift به Provider/Sandbox/E2E نیاز دارند. نردبان fidelity را نگه دارید.

برای تست موازی یک WireMock مشترک داشته باشیم؟

اگر Scenario یا Journal مشترک دارید، خطر collision بالاست. instance/dynamic port جدا یا namespace یکتای run انتخاب امن‌تری است. اشتراک فقط با state/reset و ظرفیت کنترل‌شده انجام شود.

Record/Playback امن است؟

فقط با مجوز، scope محدود، credential مصنوعی، redact، retention و review. Traffic ضبط‌شده ممکن است PII، secret، داده ناپایدار یا حتی باگ Provider را وارد repository کند.

آیا WireMock برای تست Performance مناسب است؟

برای بررسی واکنش Consumer به delay، timeout و خطا بله؛ برای ظرفیت، latency distribution و resource behavior واقعی Provider نه. آن بخش workload و محیط fidelityدار جدا می‌خواهد.

جمع‌بندی

Service Virtualization زمانی ارزش دارد که یک dependency غیرقابل‌کنترل را به آزمایش قطعی و قابل‌تشخیص تبدیل کند. WireMock ۳ ابزار قدرتمندی برای matching، state، fault، latency، verification و record/proxy است؛ ولی قدرت ابزار جای Contract، Oracle و calibration را نمی‌گیرد.

از یک dependency پرریسک و پنج failure mode شروع کنید. client واقعی را اجرا کنید، unmatched را failure نگه دارید، state را ایزوله کنید، داده حساس را حذف کنید و هر mapping را به نسخه/مالک متصل سازید. سپس با Contract، sandbox و E2E منتخب نشان دهید Virtual Service از واقعیت جدا نشده است.

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید