گاهی از اوقات، برای نوشتن آزمون‌های واحد، ایزوله سازی قسمتی که می‌خواهیم آن‌را بررسی کنیم، از سایر قسمت‌های سیستم مشکل می‌شود. برای مثال اگر در کلاسی کار اتصال به بانک اطلاعاتی صورت می‌گیرد و قصد داریم برای آن آزمون واحد بنویسیم، اما قرار نیست که الزاما با بانک اطلاعاتی کار کنیم، در این حالت نیاز به یک نمونه‌ی تقلیدی یا Mock از بانک اطلاعاتی را خواهیم داشت، تا کار دسترسی به بانک اطلاعاتی را شبیه سازی کند. در این سری با استفاده از کتابخانه‌ی بسیار معروف Moq (ماک‌یو تلفظ می‌شود؛ گاهی از اوقات هم ماک)، کار ایزوله سازی کلاس‌ها را انجام خواهیم داد، تا بتوانیم آن‌ها را مستقل از هم آزمایش کنیم.
Mocking چیست؟
فرض کنید برنامه‌ای را داریم که از تعدادی کلاس تشکیل شده‌است. در این بین می‌خواهیم تعدادی از آن‌ها را به صورت ایزوله‌ی از کل سیستم آزمایش کنیم. البته باید درنظر داشت که این کلاس‌ها در حین اجرای واقعی برنامه، از تعدادی وابستگی خاص در همان سیستم استفاده می‌کنند. برای مثال کلاسی در این بین برای بررسی میزان اعتبار مالی یک کاربر، نیاز دارد تا با یک وب سرویس خارجی کار کند. اما چون می‌خواهیم این کلاس را به صورت ایزوله‌ی از کل سیستم آزمایش کنیم، اینبار بجای استفاده‌ی از وابستگی واقعی این کلاس، آن وابستگی را با یک نمونه‌ی تقلیدی یا Mock object در اینجا، جایگزین می‌کنیم.
بنابراین Mocking به معنای جایگزین کردن یک وابستگی واقعی سیستم که در زمان اجرای آن مورد استفاده قرار می‌گیرد، با نمونه‌ی تقلیدی مختص زمان آزمایش برنامه، جهت بالابردن سهولت نوشتن آزمون‌های واحد است.
دلایل و مزایای استفاده‌ی از Mocking
- یکی از مهم‌ترین دلایل استفاده‌ی از Mocking، کاهش پیچیدگی تنظیمات اولیه‌ی نوشتن آزمون‌های واحد است. برای مثال اگر در برنامه‌ی خود از تزریق وابستگی‌ها استفاده می‌کنید و کلاسی دارای چندین وابستگی تزریق شده‌ی به آن است، برای آزمایش این کلاس نیاز به تدارک تمام این وابستگی‌ها را خواهید داشت تا بتوان این کلاس را وهله سازی کرد و همچنین برنامه را نیز کامپایل نمود. اما در این بین ممکن است آزمایش متدی در همان کلاس، الزاما از تمام وابستگی‌های تزریق شده‌ی در یک کلاس استفاده نکند. در این حالت، Mocking می‌تواند تنظیمات پیچیده‌ی وهله سازی این کلاس را به حداقل برساند.
- Mocking می‌تواند سبب افزایش سرعت اجرای آزمون‌های واحد نیز شود. برای مثال با تقلید سرویس‌های خارجی مورد استفاده‌ی در برنامه (هر عملی که از مرزهای سیستم رد شود مانند کار با شبکه، بانک اطلاعاتی، فایل سیستم و غیره)، می‌توان میزان I/O و همچنین زمان صرف شده‌ی به آن‌را به حداقل رساند.
- از mock objects می‌توان برای رهایی از مشکلات کار با مقادیر غیرمشخص استفاده کرد. برای مثال اگر در کدهای خود از DateTime.Now استفاده می‌کنید یا اعداد اتفاقی و امثال آن، هربار که آزمون‌های واحد را اجرا می‌کنیم، خروجی متفاوتی را دریافت کرده و بسیاری از آزمون‌های نوشته شده با مشکل مواجه می‌شوند. به کمک mocking می‌توان بجای این مقادیر غیرمشخص، یک مقدار ثابت و مشخص را بازگشت دهد.
- چون به سادگی می‌توان mock objects را تهیه کرد، می‌توان کار توسعه و آزمایش برنامه را پیش از به پایان رسیدن پیاده سازی اصلی سرویس‌های مدنظر، همینقدر که اینترفیس آن سرویس مشخص باشد، شروع کرد که می‌تواند برای کارهای تیمی بسیار مفید باشد.
- اگر وابستگی مورد استفاده ناپایدار و یا غیرقابل پیش بینی است، می‌توان توسط mocking به یک نمونه‌ی قابل پیش بینی و پایدار مخصوص آزمون‌های برنامه رسید.
- اگر وابستگی خارجی مورد استفاده به ازای هر بار استفاده، هزینه‌ای را شارژ می‌کند، می‌توان توسط mocking، هزینه‌ی آزمون‌های برنامه را کاهش داد.
Unit test چیست؟
بدیهی است در کنار آزمایش ایزوله‌ی قسمت‌های مختلف برنامه توسط mocking، باید کل برنامه را جهت بررسی دستیابی به نتایج واقعی نیز آزمایش کرد که به این نوع آزمون‌ها، آزمون یکپارچگی (Integration Tests)، API Tests ،UI Tests و غیره می‌گویند که در کنار Unit tests ما حضور خواهند داشت. بنابراین اکنون این سؤال مطرح می‌شود که یک Unit چیست؟
در برنامه‌ای که از چندین کلاس تشکیل می‌شود، به یک کلاس، یک Unit گفته می‌شود. همچنین اگر در این سیستم، دو یا چند کلاس با هم کار می‌کنند (کلاسی که از چندین وابستگی استفاده می‌کند)، این‌ها با هم نیز یک Unit را تشکیل دهند. بنابراین تعریف Unit بستگی به نحوه‌ی درک عملکرد یک سیستم و تعامل اجزای آن با هم دارد.
واژه‌های متناظر با Mock objects
در حین مطالعه‌ی منابع مرتبط با آزمون‌های واحد ممکن است با این واژه‌های تقریبا مشابه مواجه شوید: fakes ،stubs ،dummies و mocks. اما تفاوت آن‌ها در چیست؟
- Fakes در حقیقت یک نمونه پیاده سازی واقعی، اما غیرمناسب محیط واقعی و اصلی پروژه‌است. برای نمونه EF Core به همراه یک نمونه in-memory database هم هست که دقیقا با مفهوم Fakes تطابق دارد.
- از Dummies صرفا جهت تهیه‌ی پارامترهای مورد نیاز برای اجرای یک آزمایش استفاده می‌شوند. این پارامترها، هیچگاه در آزمایش‌های انجام شده مورد استفاده قرار نمی‌گیرند.
- از Stubs برای ارائه‌ی پاسخ‌هایی مشخص به فراخوان‌ها استفاده می‌شود. برای مثال یک متد یا خاصیت، دقیقا چه چیزی را باید بازگشت دهند.
- از Mocks برای بررسی تعامل اجزای مختلف در حال آزمایش استفاده می‌شود. آیا متدی یا خاصیتی مورد استفاده قرار گرفته‌است یا خیر؟
باید درنظر داشت که زمانیکه یک شیء Mock را توسط کتابخانه‌ی Moq تهیه می‌کنیم، هر سه مفهوم stubs ،dummies و mocks را با هم به همراه دارد. به همین جهت در این سری زمانیکه به یک mock object اشاره می‌شود، هر سه مفهوم مدنظر هستند.
واژه‌ی دیگری که ممکن است در این گروه زیاد مشاهده شود، «Test double» نام دارد که ترکیب هر 4 مورد fakes ،stubs ،dummies و mocks می‌باشد. در کل هر زمانیکه یک شیء مورد استفاده‌ی در زمان اجرای برنامه را جهت آزمایش ساده‌تر آن جایگزین می‌کنید، یک Test double را ایجاد کرده‌اید.
بررسی ساختار برنامه‌ای که می‌خواهیم آن‌را آزمایش کنیم
در این سری قصد داریم یک برنامه‌ی وام دهی را آزمایش کنیم که قسمت‌های مختلف آن دارای وابستگی‌های خاصی می‌باشند. ساختار این برنامه را در ادامه مشاهده می‌کنید:
موجودیت‌های برنامه‌ی وام دهی namespace Loans.Entities
{
public class Applicant
{
public int Id { set; get; }
public string Name { set; get; }
public int Age { set; get; }
public string Address { set; get; }
public decimal Salary { set; get; }
}
} namespace Loans.Entities
{
public class LoanProduct
{
public int Id { set; get; }
public string ProductName { set; get; }
public decimal InterestRate { set; get; }
}
} namespace Loans.Entities
{
public class LoanApplication
{
public int Id { set; get; }
public LoanProduct Product { set; get; }
public LoanAmount Amount { set; get; }
public Applicant Applicant { set; get; }
public bool IsAccepted { set; get; }
}
public class LoanAmount
{
public string CurrencyCode { get; set; }
public decimal Principal { get; set; }
}
} مدل‌های برنامه‌ی وام دهی namespace Loans.Models
{
public class IdentityVerificationStatus
{
public bool Passed { get; set; }
}
} سرویس‌های برنامه‌ی وام دهی using Loans.Models;
namespace Loans.Services.Contracts
{
public interface IIdentityVerifier
{
void Initialize();
bool Validate(string applicantName, int applicantAge, string applicantAddress);
void Validate(string applicantName, int applicantAge, string applicantAddress, out bool isValid);
void Validate(string applicantName, int applicantAge, string applicantAddress,
ref IdentityVerificationStatus status);
}
} namespace Loans.Services.Contracts
{
public interface ICreditScorer
{
int Score { get; }
void CalculateScore(string applicantName, string applicantAddress);
}
} using System;
using Loans.Entities;
using Loans.Services.Contracts;
namespace Loans.Services
{
public class LoanApplicationProcessor
{
private const decimal MinimumSalary = 1_500_000_0;
private const int MinimumAge = 18;
private const int MinimumCreditScore = 100_000;
private readonly IIdentityVerifier _identityVerifier;
private readonly ICreditScorer _creditScorer;
public LoanApplicationProcessor(
IIdentityVerifier identityVerifier,
ICreditScorer creditScorer)
{
_identityVerifier = identityVerifier ?? throw new ArgumentNullException(nameof(identityVerifier));
_creditScorer = creditScorer ?? throw new ArgumentNullException(nameof(creditScorer));
}
public bool Process(LoanApplication application)
{
application.IsAccepted = false;
if (application.Applicant.Salary < MinimumSalary)
{
return application.IsAccepted;
}
if (application.Applicant.Age < MinimumAge)
{
return application.IsAccepted;
}
_identityVerifier.Initialize();
var isValidIdentity = _identityVerifier.Validate(
application.Applicant.Name, application.Applicant.Age, application.Applicant.Address);
if (!isValidIdentity)
{
return application.IsAccepted;
}
_creditScorer.CalculateScore(application.Applicant.Name, application.Applicant.Address);
if (_creditScorer.Score < MinimumCreditScore)
{
return application.IsAccepted;
}
application.IsAccepted = true;
return application.IsAccepted;
}
}
} using System;
using Loans.Models;
using Loans.Services.Contracts;
namespace Loans.Services
{
public class IdentityVerifierServiceGateway : IIdentityVerifier
{
public DateTime LastCheckTime { get; private set; }
public void Initialize()
{
// Initialize connection to external service
}
public bool Validate(string applicantName, int applicantAge, string applicantAddress)
{
Connect();
var isValidIdentity = CallService(applicantName, applicantAge, applicantAddress);
LastCheckTime = DateTime.Now;
Disconnect();
return isValidIdentity;
}
private void Connect()
{
// Open connection to external service
}
private bool CallService(string applicantName, int applicantAge, string applicantAddress)
{
// Make call to external service, interpret the response, and return result
return false; // Simulate result for demo purposes
}
private void Disconnect()
{
// Close connection to external service
}
public void Validate(string applicantName, int applicantAge, string applicantAddress, out bool isValid)
{
throw new NotImplementedException();
}
public void Validate(string applicantName, int applicantAge, string applicantAddress,
ref IdentityVerificationStatus status)
{
throw new NotImplementedException();
}
}
} توضیحات:
هدف از این برنامه، درخواست یک وام جدید است. Application در اینجا به معنای درخواست یا فرم جدید است و Applicant نیز شخصی است که این درخواست را داده‌است.
در اینجا بیشتر تمرکز ما بر روی کلاس LoanApplicationProcessor است که دارای دو وابستگی تزریق شده‌ی به آن نیز می‌باشد:
public LoanApplicationProcessor(
IIdentityVerifier identityVerifier,
ICreditScorer creditScorer)
{
_identityVerifier = identityVerifier ?? throw new ArgumentNullException(nameof(identityVerifier));
_creditScorer = creditScorer ?? throw new ArgumentNullException(nameof(creditScorer));
}
از این وابستگی‌ها برای تصدیق هویت درخواست کننده و همچنین بررسی میزان اعتبار او استفاده می‌شود.
تمام این منطق نیز در متد Process آن قابل مشاهده‌است که هدف اصلی آن، بررسی قابل پذیرش بودن درخواست یک وام جدید است.
نوشتن اولین تست، برای برنامه‌ی وام دهی
در اولین تصویر این قسمت، پروژه‌ی class library دومی را نیز به نام Loans.Tests مشاهده می‌کنید. فایل csproj آن به صورت زیر برای کار با MSTest تنظیم شده‌است:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\Loans\Loans.csproj" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.3.0" />
<PackageReference Include="MSTest.TestAdapter" Version="2.0.0" />
<PackageReference Include="MSTest.TestFramework" Version="2.0.0" />
</ItemGroup>
</Project>
که در آن ارجاعی به پروژه‌ی Loans.csproj و همچنین وابستگی‌های MSTest، تنظیم شده‌اند.
اکنون اولین آزمون واحد ما در کلاس جدید LoanApplicationProcessorShould چنین شکلی را پیدا می‌کند:
using Loans.Entities;
using Loans.Services;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace Loans.Tests
{
[TestClass]
public class LoanApplicationProcessorShould
{
[TestMethod]
public void DeclineLowSalary()
{
var product = new LoanProduct {Id = 99, ProductName = "Loan", InterestRate = 5.25m};
var amount = new LoanAmount {CurrencyCode = "Rial", Principal = 2_000_000_0};
var applicant =
new Applicant {Id = 1, Name = "User 1", Age = 25, Address = "This place", Salary = 1_100_000_0};
var application = new LoanApplication {Id = 42, Product = product, Amount = amount, Applicant = applicant};
var processor = new LoanApplicationProcessor(null, null);
processor.Process(application);
Assert.IsFalse(application.IsAccepted);
}
}
}
در حین کار با MSTest، کلاس آزمون واحد باید به ویژگی TestClass و متدهای public void آن به ویژگی TestMethod مزین شوند تا توسط این فریم‌ورک آزمون واحد شناسایی شده و مورد آزمایش قرار گیرند.
در این آزمایش، شخص درخواست کننده، حقوق کمی دارد و می‌خواهیم بررسی کنیم که آیا LoanApplicationProcessor می‌تواند آن‌را بر اساس مقدار MinimumSalary، رد کند یا خیر؟
public class LoanApplicationProcessor
{
private const decimal MinimumSalary = 1_500_000_0;
در حین وهله سازی LoanApplicationProcessor، دو وابستگی آن به null تنظیم شده‌اند؛ چون می‌دانیم که بررسی MinimumSalary پیش از سایر بررسی‌ها صورت می‌گیرد و اساسا در این آزمایش، نیازی به این وابستگی‌ها نداریم.
اما اگر سعی در اجرای این آزمایش کنیم (برای مثال با اجرای دستور dotnet test در خط فرمان)، آزمایش اجرا نشده و با استثنای زیر مواجه می‌شویم:
Test method Loans.Tests.LoanApplicationProcessorShould.DeclineLowSalary threw exception:
System.ArgumentNullException: Value cannot be null.
Parameter name: identityVerifier
چون در سازنده‌ی کلاس LoanApplicationProcessor، در صورت نال بودن وابستگی‌های دریافتی، یک استثناء صادر می‌شود. بنابراین ذکر آن‌ها الزامی است:
public LoanApplicationProcessor(
IIdentityVerifier identityVerifier,
ICreditScorer creditScorer)
{
_identityVerifier = identityVerifier ?? throw new ArgumentNullException(nameof(identityVerifier));
_creditScorer = creditScorer ?? throw new ArgumentNullException(nameof(creditScorer));
} نصب کتابخانه‌ی Moq جهت برآورده کردن وابستگی‌های کلاس LoanApplicationProcessor
در این آزمایش چون وجود وابستگی‌های در سازنده‌ی کلاس، برای ما اهمیتی ندارند و همچنین ذکر آن‌ها نیز الزامی است، می‌خواهیم توسط
کتابخانه‌ی Moq، دو نمونه‌ی تقلیدی از آن‌ها را تهیه کرده (همان dummies که پیشتر معرفی شدند) و جهت برآورده کردن بررسی صورت گرفته‌ی در سازنده‌ی کلاس LoanApplicationProcessor، آن‌ها را ارائه کنیم.
کتابخانه‌ی بسیار معروف Moq، با پروژه‌های مبتنی بر NETFramework 4.5. و همچنین NETStandard 2.0. به بعد سازگار است و برای نصب آن، می‌توان یکی از دو دستور زیر را صادر کرد:
> dotnet add package Moq
> Install-Package Moq
اما چرا کتابخانه‌ی Moq؟
کتابخانه‌ی Moq این اهداف را دنبال می‌کند: ساده‌است، به شدت کاربردی‌است و همچنین strongly typed است. این کتابخانه
سورس باز بوده و تعداد بار دانلود بسته‌ی نیوگت آن میلیونی است.
پس از نصب آن، اولین آزمایشی را که نوشتیم، به صورت زیر اصلاح می‌کنیم:
using Loans.Entities;
using Loans.Services;
using Loans.Services.Contracts;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;
namespace Loans.Tests
{
[TestClass]
public class LoanApplicationProcessorShould
{
[TestMethod]
public void DeclineLowSalary()
{
var product = new LoanProduct {Id = 99, ProductName = "Loan", InterestRate = 5.25m};
var amount = new LoanAmount {CurrencyCode = "Rial", Principal = 2_000_000_0};
var applicant =
new Applicant {Id = 1, Name = "User 1", Age = 25, Address = "This place", Salary = 1_100_000_0};
var application = new LoanApplication {Id = 42, Product = product, Amount = amount, Applicant = applicant};
var mockIdentityVerifier = new Mock<IIdentityVerifier>();
var mockCreditScorer = new Mock<ICreditScorer>();
var processor = new LoanApplicationProcessor(mockIdentityVerifier.Object, mockCreditScorer.Object);
processor.Process(application);
Assert.IsFalse(application.IsAccepted);
}
}
}
در اینجا بجای ارسال null به سازنده‌ی کلاس LoanApplicationProcessor، جهت برآورده کردن مقدار پیش‌فرض پارامترهای آن و کامپایل شدن برنامه، نمونه‌های تقلیدی دو وابستگی مورد نیاز آن‌را تهیه و به آن ارسال کرده‌ایم.
کار با ذکر new Mock شروع شده و آرگومان جنریک آن‌را از نوع وابستگی‌هایی که نیاز داریم، مقدار دهی می‌کنیم. سپس خاصیت Object آن، امکان دسترسی به این شیء تقلید شده را میسر می‌کند.
اکنون اگر مجددا این آزمون واحد را اجرا کنیم، مشاهده خواهیم کرد که بجای صدور استثناء، با موفقیت به پایان رسیده‌است:
گاهی از اوقات جایگزین کردن یک وابستگی null با نمونه‌ی Mock آن کافی نیست
در مثالی که بررسی کردیم، اشیاء mock، کار برآورده کردن نیازهای ابتدایی آزمایش را انجام داده و سبب اجرای موفقیت آمیز آن شدند؛ اما همیشه اینطور نیست:
using Loans.Entities;
using Loans.Services;
using Loans.Services.Contracts;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;
namespace Loans.Tests
{
[TestClass]
public class LoanApplicationProcessorShould
{
[TestMethod]
public void Accept()
{
var product = new LoanProduct {Id = 99, ProductName = "Loan", InterestRate = 5.25m};
var amount = new LoanAmount {CurrencyCode = "Rial", Principal = 2_000_000_0};
var applicant =
new Applicant {Id = 1, Name = "User 1", Age = 25, Address = "This place", Salary = 1_500_000_0};
var application = new LoanApplication {Id = 42, Product = product, Amount = amount, Applicant = applicant};
var mockIdentityVerifier = new Mock<IIdentityVerifier>();
var mockCreditScorer = new Mock<ICreditScorer>();
var processor = new LoanApplicationProcessor(mockIdentityVerifier.Object, mockCreditScorer.Object);
processor.Process(application);
Assert.IsTrue(application.IsAccepted);
}
}
}
تفاوت این آزمایش جدید با قبلی، در دو مورد است: مقدار Salary به MinimumSalary تنظیم شده‌است و در آخر Assert.IsTrue را داریم.
اگر این آزمایش را اجرا کنیم، با شکست مواجه خواهد شد. علت اینجا است که هرچند در حال استفاده‌ی از دو mock object به عنوان وابستگی‌های مورد نیاز هستیم، اما تنظیمات خاصی را بر روی آن‌ها انجام نداده‌ایم و به همین جهت خروجی مناسبی را در اختیار LoanApplicationProcessor قرار نمی‌دهند. برای مثال مرحله‌ی بعدی بررسی اعتبار شخص در کلاس LoanApplicationProcessor، فراخوانی سرویس identityVerifier و متد Validate آن است که خروجی آن بر اساس کدهای فعلی، همیشه false است:
_identityVerifier.Initialize();
var isValidIdentity = _identityVerifier.Validate(
application.Applicant.Name, application.Applicant.Age, application.Applicant.Address);
در قسمت بعدی، کار تنظیم اشیاء mock را انجام خواهیم داد.
کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید: MoqSeries-01.zip 
