👆 🌆 🙎🏿 यूनिट अभ्यास परीक्षण 👨‍👧 🏗️ 🤕

हाल ही में, परीक्षण के माध्यम से विकास के विषय पर बहुत सारे प्रकाशन दिखाई दिए हैं और दिखाई देते हैं। विषय काफी दिलचस्प है और इसे शोध करने के लिए अपने समय के कुछ हिस्से को समर्पित करने के लिए इसके लायक है। हमारी टीम में, हम एक वर्ष से अधिक समय से यूनिट परीक्षण का उपयोग कर रहे हैं। इस लेख में मैं इस बारे में बात करना चाहता हूं कि क्या हुआ और आखिरकार हमें किस तरह का अनुभव प्राप्त हुआ।

मुझे तुरंत कहना होगा कि उदाहरण C # भाषा और .NET प्लेटफ़ॉर्म के संबंध में दिए गए हैं। तदनुसार, अन्य भाषाओं / प्लेटफार्मों में, दृष्टिकोण और कार्यान्वयन भिन्न हो सकते हैं।

इसलिए ...

यूनिट टेस्ट क्या होना चाहिए?

इस तथ्य के अलावा कि इकाई परीक्षणों को सॉफ़्टवेयर उत्पाद की कार्यक्षमता से मेल खाना चाहिए, मुख्य आवश्यकता गति है। यदि परीक्षण सूट लॉन्च करने के बाद डेवलपर ब्रेक ले सकता है (मेरे मामले में स्मोक ब्रेक के लिए), तो इस तरह के लॉन्च कम और कम (फिर से, मेरे मामले में, निकोटीन की अधिकता के डर के कारण) होंगे। परिणामस्वरूप, यह पता चल सकता है कि इकाई परीक्षण बिल्कुल नहीं चलेंगे और परिणामस्वरूप, उन्हें लिखने का अर्थ खो जाएगा। एक प्रोग्रामर को किसी भी समय पूरे टेस्ट सूट को चलाने में सक्षम होना चाहिए। और इस सेट को जितनी जल्दी हो सके निष्पादित करना चाहिए।

यूनिट परीक्षणों की गति सुनिश्चित करने के लिए किन आवश्यकताओं का पालन करना चाहिए?

टेस्ट छोटे होने चाहिए

आदर्श मामले में, प्रति परीक्षण एक जोर देता है। यूनिट टेस्ट द्वारा कवर की गई कार्यक्षमता का टुकड़ा जितना छोटा होगा, परीक्षण उतनी ही तेजी से चलेगा।

वैसे, डिजाइन के विषय पर। मैं वास्तव में उस दृष्टिकोण को पसंद करता हूं जिसे "अरेंज-एक्ट-एश्योर" के रूप में तैयार किया गया है।
इसका सार एक इकाई परीक्षण में स्पष्ट रूप से पूर्व शर्त को परिभाषित करना है (परीक्षण डेटा का प्रारंभ,
प्रीसेट), एक्शन (वास्तव में क्या परीक्षण किया जा रहा है) और पोस्टकंडिशन (जो होना चाहिए
कार्रवाई का परिणाम)। यह डिज़ाइन परीक्षण की पठनीयता को बढ़ाता है और इसे आसान बनाता है
परीक्षण की कार्यक्षमता के लिए प्रलेखन के रूप में उपयोग करें।

यदि विकास JetBrains से ReSharper का उपयोग करता है, तो एक टेम्प्लेट केस के लिए रिक्त बनाने के लिए उपयोग किए जाने वाले टेम्पलेट को कॉन्फ़िगर करना बहुत सुविधाजनक है। उदाहरण के लिए, टेम्पलेट इस तरह दिख सकता है:

[Test] public void Test_$METHOD_NAME$() { //arrange $END$ //act //assert Assert.Fail("Not implemented"); }

और फिर परीक्षण, इस तरह से डिज़ाइन किया गया, कुछ इस तरह दिख सकता है (सभी नाम काल्पनिक हैं, संयोग यादृच्छिक हैं):

 [Test] public void Test_ForbiddenForPackageChunkWhenPackageNotFound() { //arrange var packagesRepositoryMock = _mocks.Create<IPackagesRepository>(); packagesRepositoryMock .Setup(r => r.FindPackageAsync(_packageId)) .Returns(Task<DatabasePackage>.Factory.StartNew(() => null)); Register(packagesRepositoryMock.Object); //act var message = PostChunkToServer(new byte[] { 1, 2, 3 }); //assert _mocks.VerifyAll(); Assert.That(message.StatusCode, Is.EqualTo(HttpStatusCode.Forbidden)); }

टेस्ट को पर्यावरण (डेटाबेस, नेटवर्क, फाइल सिस्टम) से अलग किया जाना चाहिए

यह आइटम शायद सभी का सबसे विवादास्पद है। अक्सर साहित्य में ऐसे कार्यों पर टीडीडी के उपयोग के उदाहरणों के रूप में कैलकुलेटर या टेलीफोन निर्देशिका के विकास पर विचार किया जाता है। यह स्पष्ट है कि इन कार्यों को वास्तविकता से अलग किया जाता है और डेवलपर, अपनी परियोजना में लौटकर, रोजमर्रा के काम में ज्ञान और कौशल को लागू करना नहीं जानता है। कुख्यात कैलकुलेटर के समान सरलतम मामले, यूनिट परीक्षणों द्वारा कवर किए जाते हैं, और बाकी की कार्यक्षमता एक ही रेल पर विकसित की जाती है। नतीजतन, यूनिट परीक्षणों पर समय बिताने की समझ क्यों गायब हो जाती है यदि सरल कोड को वैसे भी डिबग किया जा सकता है, और जटिल कोड को वैसे भी परीक्षण द्वारा कवर नहीं किया जाता है।

वास्तव में, यूनिट परीक्षणों में डेटाबेस या फ़ाइल सिस्टम का उपयोग करना ठीक है। तो, कम से कम, आप कार्यक्षमता की कार्यक्षमता के बारे में सुनिश्चित हो सकते हैं, जो सिस्टम के मूल का गठन करता है। एकमात्र सवाल यह है कि परीक्षण के अलगाव और उनके निष्पादन की गति के बीच संतुलन बनाए रखते हुए, सबसे कुशल तरीके से बाहरी वातावरण का उपयोग कैसे किया जाता है?

केस 1. डेटा एक्सेस लेयर (MS SQL सर्वर)

यदि किसी प्रोजेक्ट के विकास में MS SQL सर्वर का उपयोग किया जाता है, तो इस प्रश्न का उत्तर एक परीक्षण डेटाबेस को तैनात करने के लिए MS SQL सर्वर (एक्सप्रेस, एंटरप्राइज या डेवलपर संस्करण) के स्थापित इंस्टेंस का उपयोग करने के लिए हो सकता है। एक समान डेटाबेस को MS SQL प्रबंधन स्टूडियो में उपयोग किए जाने वाले मानक तंत्रों का उपयोग करके बनाया जा सकता है और इकाई परीक्षणों के साथ एक परियोजना में रखा जा सकता है। इस तरह के डेटाबेस का उपयोग करने के लिए एक सामान्य दृष्टिकोण एक परीक्षण प्रदर्शन करने से पहले एक परीक्षण डेटाबेस को तैनात करना है (उदाहरण के लिए, NUnit का उपयोग करते समय SetUp विशेषता के साथ चिह्नित विधि में), परीक्षण डेटा के साथ डेटाबेस को भरना, और इन प्रसिद्ध परीक्षण डेटा पर रिपॉजिटरी या गेटवे की कार्यक्षमता की जांच करना। इसके अलावा, परीक्षण डेटाबेस को हार्ड डिस्क पर और मेमोरी में उन अनुप्रयोगों का उपयोग करके तैनात किया जा सकता है जो रैम डिस्क का निर्माण और प्रबंधन करते हैं। मान लीजिए कि फिलहाल मैं जिस प्रोजेक्ट पर काम कर रहा हूं, वह सॉफ्टपेयर रैम डिस्क एप्लिकेशन का उपयोग करता है। यूनिट परीक्षणों में रैम डिस्क का उपयोग करने से आपको I / O संचालन के दौरान होने वाली देरी को कम करने की अनुमति मिलती है जो तब होता है जब परीक्षण डेटाबेस को हार्ड डिस्क पर तैनात किया गया था। बेशक, यह दृष्टिकोण आदर्श नहीं है, क्योंकि इसके लिए डेवलपर के वातावरण में तीसरे पक्ष के सॉफ़्टवेयर की आवश्यकता होती है। दूसरी ओर, यह देखते हुए कि विकास के वातावरण को तैनात किया जाता है, एक नियम के रूप में, एक बार (अच्छी तरह से, या शायद ही कभी पर्याप्त), यह आवश्यकता इतनी बोझ नहीं लगती है। और इस दृष्टिकोण का उपयोग करने से लाभ काफी लुभावना है, क्योंकि सिस्टम की सबसे महत्वपूर्ण परतों में से एक के सही संचालन को नियंत्रित करना संभव हो जाता है।

वैसे, यदि यूनिट परीक्षणों में MS SQL सर्वर में यूनिट परीक्षणों के लिए LINQ2SQL और SMO का उपयोग करना संभव है, तो आप डेटा एक्सेस लेयर का परीक्षण करने के लिए निम्न बेस क्लास का उपयोग कर सकते हैं:

कोड

 public abstract class DatabaseUnitTest<TContext> where TContext : DataContext { [TestFixtureSetUp] public void FixtureSetUp() { CreateFolderForTempDatabase(); } [SetUp] public void BeforeTestExecuting() { RestoreDatabaseFromOriginal(); RecreateContext(); } [TestFixtureTearDown] public void FixtureTearDown() { KillDatabase(); } protected string ConnectionString { get { return String.Format(@"Data Source={0};Initial Catalog={1};Integrated Security=True", TestServerName, TestDatabaseName); } } protected TContext Context { get; private set; } protected string TestDatabaseOriginalName { get { return "Database"; } } protected string ProjectName { get { return "CoolProject"; } } protected void RecreateContext() { Context = (TContext) Activator.CreateInstance(typeof(TContext), ConnectionString); } private string FolderForTempDatabase { get { return String.Format(@"R:\{0}.DatabaseTests\", ProjectName); } } private string TestDatabaseName { get { return FolderForTempDatabase + ProjectName + ".Tests"; } } private string TestDatabaseOriginalFileName { get { return Path.Combine(TestDatabaseDirectory, TestDatabaseOriginalName + ".mdf"); } } private string TestDatabaseFileName { get { return Path.Combine(TestDatabaseDirectory, TestDatabaseName + ".mdf"); } } private void CreateFolderForTempDatabase() { var directory = new DirectoryInfo(FolderForTempDatabase); if(!directory.Exists) { directory.Create(); } } private void RestoreDatabaseFromOriginal() { KillDatabase(); CopyFiles(); AttachDatabase(); } private void KillDatabase() { Server server = Server; SqlConnection.ClearAllPools(); if(server.Databases.Contains(TestDatabaseName)) { server.KillDatabase(TestDatabaseName); } } private void CopyFiles() { new FileInfo(TestDatabaseOriginalFileName).CopyTo(TestDatabaseFileName, true); string logFileName = GetLogFileName(TestDatabaseFileName); new FileInfo(GetLogFileName(TestDatabaseOriginalFileName)).CopyTo(logFileName, true); new FileInfo(TestDatabaseFileName).Attributes = FileAttributes.Normal; new FileInfo(logFileName).Attributes = FileAttributes.Normal; } private void AttachDatabase() { Server server = Server; if(!server.Databases.Contains(TestDatabaseName)) { server.AttachDatabase(TestDatabaseName, new StringCollection {TestDatabaseFileName, GetLogFileName(TestDatabaseFileName)}); } } private static string GetLogFileName(string databaseFileName) { return new Regex(".mdf$", RegexOptions.IgnoreCase).Replace(databaseFileName, "_log.ldf"); } private static Server Server { get { return new Server(TestServerName); } } private static string TestServerName { get { return "."; } } private static string TestDatabaseDirectory { get { var debugDirectory = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory); DirectoryInfo binDirectory = debugDirectory.Parent; DirectoryInfo testProjectDirectory; if(binDirectory == null || (testProjectDirectory = binDirectory.Parent) == null) { throw new Exception(""); } return Path.Combine(testProjectDirectory.FullName, "Database"); } } }

डेटाबेस के साथ बातचीत के लिए कौन से परीक्षण का उपयोग करने के बाद कुछ इस तरह दिखाई देगा:

 [TestFixture] public class ObjectFinderTest : DatabaseUnitTest<DatabaseDataContext> { [Test] public void Test_NullWhenObjectNotExists() { //arrange var fakeIdentifier = 0; var finder = new ObjectFinder(fakeIdentifier, ConnectionString); //act var foundObject = finder.Find(); //assert Assert.That(foundObject, Is.Null); } [Test] public void Test_SuccessfullyFound() { //arrange var insertedObject = ObjectsFactory.Create(); Context.Objects.InsertOnSubmit(insertedObject); Context.SubmitChanges(); var finder = new ObjectFinder(insertedObject.Id, ConnectionString); //act var foundObject = finder.Find(); //assert Assert.That(foundObject.Id, Is.EqualTo(insertedObject.Id)); Assert.That(foundObject.Property, Is.EqualTo(insertedObject.Property)); } }

देखा! हमें डेटाबेस एक्सेस लेयर का परीक्षण करने का अवसर मिला।

केस 2. ASP.NET MVC WebAPI

WebAPI का परीक्षण करते समय, एक प्रश्न यह है कि इकाई परीक्षण कैसे बनाया जाए ताकि आप किसी विशिष्ट url के लिए अनुरोध भेजते समय सही तर्कों के साथ सही नियंत्रकों पर सही तरीकों से कॉलिंग परीक्षण कर सकें। यदि हम मानते हैं कि नियंत्रक की जिम्मेदारी केवल कॉल को सिस्टम के संबंधित वर्ग या घटक पर पुनर्निर्देशित करना है, तो नियंत्रक के परीक्षण के बारे में सवाल का जवाब इस तथ्य से कम हो जाएगा कि परीक्षण शुरू करने से पहले, गतिशील रूप से कुछ ऐसे वातावरण का निर्माण करें जिसमें नियंत्रक आवश्यक HTTP अनुरोध भेज सके और कॉन्फ़िगर मार्ग की शुद्धता की जांच करने के लिए मोक्स का उपयोग करना। उसी समय, मैं परीक्षण वातावरण को तैनात करने के लिए IIS का उपयोग नहीं करना चाहता हूं। आदर्श रूप से, प्रत्येक परीक्षण को चलाने से पहले एक परीक्षण वातावरण बनाया जाना चाहिए। इससे यूनिट परीक्षणों को एक दूसरे से पर्याप्त रूप से अलग होने में मदद मिलेगी। IIS के साथ, इस संबंध में यह काफी मुश्किल होगा।

सौभाग्य से, .NET फ्रेमवर्क 4.5 की रिलीज के साथ, परीक्षण रूटिंग की समस्या को काफी सरलता से हल करना संभव हो गया। उदाहरण के लिए, निम्न वर्गों (एकता का उपयोग DI कंटेनर के रूप में किया जाता है) का उपयोग करना:

कोड

 public abstract class AbstractControllerTest<TController> where TController : ApiController { private HttpServer _server; private HttpClient _client; private UnityContainer _unityContainer; [SetUp] public void BeforeTestExecuting() { _unityContainer = new UnityContainer(); var configuration = new HttpConfiguration(); WebApiConfig.Register(configuration, new IoCContainer(_unityContainer)); _server = new HttpServer(configuration); _client = new HttpClient(_server); Register<TController>(); RegisterConstructorDependenciesAndInjectionProperties(typeof(TController)); } [TearDown] public void AfterTestExecuted() { _client.Dispose(); _server.Dispose(); _unityContainer.Dispose(); } protected TestHttpRequest CreateRequest(string url) { return new TestHttpRequest(_client, url); } protected void Register<T>(T instance) { Register(typeof(T), instance); } private void Register(Type type, object instance) { _unityContainer.RegisterInstance(type, instance); } private void Register<T>() { _unityContainer.RegisterType<T>(); } private void RegisterConstructorDependenciesAndInjectionProperties(Type controllerType) { var constructors = controllerType.GetConstructors(); var constructorParameters = constructors .Select(constructor => constructor.GetParameters()) .SelectMany(constructorParameters => constructorParameters); foreach (var constructorParameter in constructorParameters) { RegisterMockType(constructorParameter.ParameterType); } var injectionProperties = controllerType.GetProperties() .Where(info => info.GetCustomAttributes(typeof(DependencyAttribute), false) .Any()); foreach (var property in injectionProperties) { RegisterMockType(property.PropertyType); } } private void RegisterMockType(Type parameterType) { dynamic mock = Activator.CreateInstance(typeof(Mock<>).MakeGenericType(parameterType), new object[] { MockBehavior.Default }); Register(parameterType, mock.Object); } }

 public sealed class TestHttpRequest { private readonly HttpClient _client; private readonly Uri _uri; public TestHttpRequest(HttpClient client, string url) { _client = client; _uri = new Uri(new Uri("http://can.be.anything/"), url); } public void AddHeader(string header, object value) { _client.DefaultRequestHeaders.Add(header, value.ToString()); } public HttpResponseMessage Get() { return _client.GetAsync(_uri).Result; } public HttpResponseMessage Post(byte[] content) { return _client.PostAsync(_uri, new ByteArrayContent(content)).Result; } public HttpResponseMessage Put(byte[] content) { return _client.PutAsync(_uri, new ByteArrayContent(content)).Result; } public HttpResponseMessage Head() { var message = new HttpRequestMessage(HttpMethod.Head, _uri); return _client.SendAsync(message).Result; } }

अब आप इन वर्गों का उपयोग एक काल्पनिक नियंत्रक का परीक्षण करने के लिए कर सकते हैं जो क्रमबद्ध दिनांक और एक निश्चित प्लेटफ़ॉर्म वर्ग की वस्तुओं को लौटाता है।

 [TestFixture] public class MyControllerTest : AbstractControllerTest<MyController> { private MockRepository _mocks; protected override void OnSetup() { _mocks = new MockRepository(MockBehavior.Strict); } [Test] public void Test_GetDates() { //arrange var january = new DateTime(2013, 1, 1); var february = new DateTime(2013, 2, 1); var repositoryMock = _mocks.Create<IRepository>(); repositoryMock .Setup(r => r.GetDates()) .Returns(new[] {january, february}); Register(repositoryMock.Object); //act var dates = ExecuteGetRequest<DateTime[]>("/api/build-dates"); //assert _mocks.VerifyAll(); Assert.That(dates, Is.EquivalentTo(new[] { january, february })); } [Test] public void Test_GetPlatforms() { //arrange var platform1 = new Platform {Id=1, Name = "1"}; var platform2 = new Platform {Id=2, Name = "2"}; var repositoryMock = _mocks.Create<IRepository>(); repositoryMock .Setup(r => r.GetPlatforms()) .Returns(new[] { platform1, platform2 }); Register(repositoryMock.Object); //act var platforms = ExecuteGetRequest<Platform[]>("/api/platforms"); //assert _mocks.VerifyAll(); Assert.That(platforms, Is.EquivalentTo(new[] { platform1, platform2 })); } private T ExecuteGetRequest<T>(string uri) { var request = CreateRequest(url); var response = request.Get(); T result; response.TryGetContentValue(out result); return result; } }

बस इतना ही। हमारे नियंत्रक इकाई परीक्षणों द्वारा कवर किए गए हैं।

केस 3. सब कुछ

और सब कुछ के साथ, यह काफी सरल है। उन कक्षाओं के लिए यूनिट परीक्षणों के उदाहरण जिनमें शुद्ध तर्क होते हैं, बिना किसी बाहरी वातावरण के साथ बातचीत किए, व्यावहारिक रूप से उन लोगों से अलग नहीं होते हैं जो उदाहरण के प्रकार से केंट बेक टीडीडी के लोकप्रिय साहित्य में पेश किए जाते हैं। इसलिए, यहां कोई विशेष चाल नहीं है।

मैं जोड़ूंगा कि प्रोग्राम लॉजिक में त्रुटियों की संख्या को कम करने के अलावा, यूनिट परीक्षणों का उपयोग निम्नलिखित लाभ भी प्रदान करता है:

अनुप्रयोग वास्तुकला का सरलीकरण। यहाँ मूल नियम निम्नानुसार तैयार किया गया है: "केवल वही है जो वास्तव में आवश्यक है, एहसास है।" यदि परीक्षण में सभी परिदृश्यों का वर्णन किया गया है और अब आप तर्क को तोड़ने के तरीके का पता नहीं लगा सकते हैं, तो आपको रोकने की आवश्यकता है, कोड को अधिक या कम सभ्य रूप (रिफ्लेक्टर) में लाएं और एक स्पष्ट विवेक के साथ बिस्तर पर जाएं।
प्रलेखन कोड। संकलित और निष्पादन योग्य उपयोग मामलों से बेहतर क्या हो सकता है? एक अच्छी तरह से लिखित परीक्षा उत्कृष्ट प्रलेखन है, जो टिप्पणियों के विपरीत, इसकी प्रासंगिकता नहीं खोएगी। जब तक, निश्चित रूप से, प्रोग्राम लॉजिक के कार्यान्वयन को बदलने पर परीक्षणों के सफल मार्ग को नियंत्रित किया जाता है।
"Airbag"। यह, मेरी राय में, परियोजना में टीडीडी के उपयोग से प्राप्त किया जा सकता सबसे महत्वपूर्ण लाभ है। परीक्षण यह गारंटी देंगे कि एक प्रोग्रामर जो कोड से अपरिचित है, तुरंत यह देखने में सक्षम होगा कि क्या परिवर्तनों ने कार्यक्रम में खराबी की है। वास्तविक और पूर्ण इकाई परीक्षण उत्कृष्ट प्रतिक्रिया देते हैं। वैसे, "एयरबैग" के संदर्भ में, कोई भी स्पष्ट रूप से स्पष्ट कोड के लिए इकाई परीक्षण लिखने की सलाह के सवाल का जवाब दे सकता है। टीम के विकास के मामले में, जो एक डेवलपर के लिए स्पष्ट है वह दूसरे के लिए पूरी तरह से स्पष्ट नहीं हो सकता है। विभिन्न कारणों से। डेवलपर्स के पेशेवर स्तर में अंतर के कारण शामिल हैं (हम टीम को याद करते हैं, सही?)। और एक स्थिति उत्पन्न हो सकती है जब इस दूसरे को कोड में परिवर्तन करना होगा जो कि स्पष्ट नहीं है या बस उसके लिए अपरिचित नहीं है। और इस मामले में, यूनिट परीक्षण प्रणाली को व्यवधान से बचा सकते हैं और डेवलपर्स को अपने कार्यों को अधिक आत्मविश्वास और कुशलता से करने की अनुमति देते हैं।

यह शायद ध्यान देने योग्य है कि सूचीबद्ध "बन्स" हमेशा ताजा और स्वादिष्ट होगा, "परीक्षण पहले" के सिद्धांत के अधीन। क्या आवश्यकताएँ बदल गई हैं? एक परीक्षण जोड़ें, कोड बदलें। त्रुटि ठीक करें? एक परीक्षण जोड़ें, कोड बदलें। सबसे कठिन हिस्सा परीक्षणों की धारणा को बदलना है। यूनिट परीक्षणों को अक्सर "मुख्य" कोड के लिए कुछ विदेशी माना जाता है। यह, मेरी राय में, टीडीडी को पूर्ण रूप से उपयोग करने के लिए मुख्य बाधा है। और इसे दूर किया जाना चाहिए, यह महसूस करने के लिए कि यूनिट परीक्षण और प्रोग्राम की गई कार्यक्षमता एक पूरे के हिस्से हैं।

आज तक, हमारी टीम जिस परियोजना पर काम कर रही है, उसमें लगभग 1,000 यूनिट परीक्षण हैं। TeamCity पर सभी परीक्षणों का निर्माण और लॉन्च का समय 4 मिनट से थोड़ा अधिक है। लेख में वर्णित दृष्टिकोण हमें कोड के परिवर्तन और विकास को नियंत्रित करने, सिस्टम की लगभग सभी परतों का परीक्षण करने की अनुमति देते हैं। मुझे उम्मीद है कि हमारा अनुभव किसी के लिए उपयोगी होगा।

यूनिट अभ्यास परीक्षण

More articles: