Summarize this content to 400 words in Persian Lang
چگونه باید تست های واحد خود را نام گذاری کنید؟ چه استانداردهایی باید برای نام آنها در نظر بگیرید؟
چه کسی اهمیت می دهد.
من قصد ندارم ساختار و قالب دقیقی را که باید استفاده کنید به شما بگویم. این به شما، شرکتتان، مدیر فنی شما، یا هر کسی که فکر می کند مهم است بستگی دارد.
چیزی که من اینجا هستم تا به شما بگویم این است که موارد خاصی وجود دارد که باید همیشه هنگام نامگذاری تست های واحد و این موارد انجام دهید بسیار مهم است که این کارها انجام شود.
پس این موارد مهمی که باید هنگام نامگذاری تست های واحد انجام دهید چیست؟
آنها باید به گونه ای نامگذاری شوند که به شما بگوید چیست سناریو آنها در حال آزمایش هستند و چه چیزی نتیجه باید باشد. بدیهی به نظر می رسد، اما کمی هنر در این وجود دارد، و انجام اشتباه بسیار آسان است.
چرا مهم است که تست های واحد به شما بگویند که چه کاری انجام می دهند؟ به این دلیل است که برنامه نویسی یک ورزش گروهی است. کد نیاز به خواندن و نگهداری دارد. تست های واحد کد هستند و همچنین به عنوان مستندی از عملکرد شما عمل می کنند. گاهی اوقات بیشتر از خود کد.
افراد دیگر (از جمله شما آینده) باید بتوانند به نام آزمون نگاه کنند و بدانند که چه چیزی به طور خاص مورد آزمایش قرار می گیرد. نه فقط چه، بلکه چه زمانی. چیزی که شما آزمایش می کنید چه زمانی اتفاق می افتد؟ چه چیزی مختص این سناریوی خاص است که آن را خاص می کند؟
نمونه ای از نامگذاری که بد انجام می شود Verify_Process است. راستی آزمایی واقعاً به چه معناست و فرآیند چیست؟
اوه، روشی که شما آزمایش می کنید “SomethingProcess()” نام دارد؟ خوب این یک مشکل است. نام آن را تغییر دهید تا توضیح دهید که “فرایند” دقیقاً چه کاری انجام می دهد!
همچنین، تأیید به من چیزی نمی گوید. چه چیزی را تأیید می کنید؟ چه چیزی باعث می‌شود چیزی که آزمایش می‌کنید «تأیید شده» شود؟ کسی که در 18 ماه به این کد نگاه می کند چگونه با دیدن این نام متوجه می شود؟ اگر آنها نتوانند هدف آن را از روی نام تعیین کنند، در نهایت مجبور به بررسی کد تست خواهند شد، که روند بسیار کندتری دارد.
به ما گفتن آنچه که آزمون انجام می دهد نیز کافی نیست. AddNewCustomerTest کافی نیست. چه سناریویی را آزمایش می کنید؟ اینکه یک مشتری جدید می تواند اضافه شود یک سناریو نیست بلکه یک اقدام است. در مورد آزمایش زمانی که مشتری به دلایلی با موفقیت اضافه نشده است، یا زمانی که آنها اضافه شده اند اما از قبل وجود دارند، چطور؟
همچنین چه زمانی اضافه می شوند؟ برای مثال، می‌توانید نام آزمایش را: WhenCustomerHasFullName_CustomerAddedSuccessfully. در اینجا تستی وجود دارد که سناریویی را آزمایش می کند که چه زمانی نام کامل مشتری در پست درج شده است. این نام شامل سناریوی “وقتی نام کامل مشتری وارد می شود” و انتظار می رود: “مشتری با موفقیت اضافه شد”.
گنجاندن سناریو بخش مهمی از نام آزمون شما است. شرایط عملی که انجام می دهید را توضیح می دهد. “وقتی این کار را انجام می دهم”. “وقتی این داده ها گنجانده شود”. “وقتی سعی می کنم به عنوان یک مدیر به این دسترسی داشته باشم”.
انتظار نتیجه مورد انتظار شماست. نتیجه آزمون. این به اندازه سناریو بسیار مهم است. آنها با هم ترکیبی را تشکیل می دهند که دلیل وجود آزمون را توضیح می دهد. “وقتی این اتفاق می افتد، باید این اتفاق بیفتد.”
ممکن است برخی از شما از الگوی “SystemUnderTest_When_Then” برای نامگذاری تست ها آگاه باشید. این خوب است، و من این ساختار را توصیه می کنم، اما فقط به این دلیل که شامل سناریو و انتظارات است. سیستم در حال آزمایش، یا چیزی که شما در حال آزمایش آن هستید، البته توصیفی و مفید است، اما با نگاه کردن به کد به راحتی می توان آن را استنباط کرد (برخلاف سناریو؛ و معمولاً انتظارات را می توان به راحتی از ادعاها به دست آورد) و همچنین ، می توانید این را در نام کلاس، برچسب ها یا برخی توصیفگرهای دیگر قرار دهید.
این است سناریو و انتظار که هر کسی که به تست ها نگاه می کند می خواهد بداند. اینها بخشهای مهم نام یک آزمون هستند.
درست بودن این موضوع نه تنها به این معنی است که آزمون‌های شما به راحتی قابل پیگیری و درک هستند، بلکه شما را تشویق می‌کند تا ترکیب‌های بیشتری را در نظر بگیرید. می‌توانید این ترکیب‌های سناریو/انتظارات را قبل از اینکه تست‌ها را کامل کنید، بنویسید. اگر بخواهید نام آزمایشی را «GetTimeZoneTest» یا «FileProcessorTest» بگذارید، چگونه این کار را انجام می دهید؟
همچنین شایان ذکر است که می‌توانید هر آنچه را که در اینجا در مورد آن صحبت می‌کنم، در «ویژگی‌های توصیف» یا «موردهای آزمایشی»، در صورت ترجیح، به جای نام آزمون اضافه کنید. نکته این است که مشخص است آزمایش ها چه می کنند.
با گنجاندن سناریو و انتظارات در نام‌ها/توضیحات آزمون، شما را تشویق می‌کند که مانند یک آزمایش‌کننده فکر کنید. نگران خواهید شد چرا شما در حال نوشتن تست ها هستید و یاد می گیرید که سناریوها را با انتظارات مرتبط کنید.
همچنین خواندن تست های شما را آسان می کند و اسناد مفیدی را برای نگهبانان آینده تشکیل می دهد.
چگونه باید تست های واحد خود را نام گذاری کنید؟ چه استانداردهایی باید برای نام آنها در نظر بگیرید؟
چه کسی اهمیت می دهد.
من قصد ندارم ساختار و قالب دقیقی را که باید استفاده کنید به شما بگویم. این به شما، شرکتتان، مدیر فنی شما، یا هر کسی که فکر می کند مهم است بستگی دارد.
چیزی که من اینجا هستم تا به شما بگویم این است که موارد خاصی وجود دارد که باید همیشه هنگام نامگذاری تست های واحد و این موارد انجام دهید بسیار مهم است که این کارها انجام شود.
پس این موارد مهمی که باید هنگام نامگذاری تست های واحد انجام دهید چیست؟
آنها باید به گونه ای نامگذاری شوند که به شما بگوید چیست سناریو آنها در حال آزمایش هستند و چه چیزی نتیجه باید باشد. بدیهی به نظر می رسد، اما کمی هنر در این وجود دارد، و انجام اشتباه بسیار آسان است.
چرا مهم است که تست های واحد به شما بگویند که چه کاری انجام می دهند؟ به این دلیل است که برنامه نویسی یک ورزش گروهی است. کد نیاز به خواندن و نگهداری دارد. تست های واحد کد هستند و همچنین به عنوان مستندی از عملکرد شما عمل می کنند. گاهی اوقات بیشتر از خود کد.
افراد دیگر (از جمله شما آینده) باید بتوانند به نام آزمون نگاه کنند و بدانند که چه چیزی به طور خاص مورد آزمایش قرار می گیرد. نه فقط چه، بلکه چه زمانی. چیزی که شما آزمایش می کنید چه زمانی اتفاق می افتد؟ چه چیزی مختص این سناریوی خاص است که آن را خاص می کند؟
نمونه ای از نامگذاری که بد انجام می شود Verify_Process است. راستی آزمایی واقعاً به چه معناست و فرآیند چیست؟
اوه، روشی که شما آزمایش می کنید “SomethingProcess()” نام دارد؟ خوب این یک مشکل است. نام آن را تغییر دهید تا توضیح دهید که “فرایند” دقیقاً چه کاری انجام می دهد!
همچنین، تأیید به من چیزی نمی گوید. چه چیزی را تأیید می کنید؟ چه چیزی باعث می‌شود چیزی که آزمایش می‌کنید «تأیید شده» شود؟ کسی که در 18 ماه به این کد نگاه می کند چگونه با دیدن این نام متوجه می شود؟ اگر آنها نتوانند هدف آن را از روی نام تعیین کنند، در نهایت مجبور به بررسی کد تست خواهند شد، که روند بسیار کندتری دارد.
به ما گفتن آنچه که آزمون انجام می دهد نیز کافی نیست. AddNewCustomerTest کافی نیست. چه سناریویی را آزمایش می کنید؟ اینکه یک مشتری جدید می تواند اضافه شود یک سناریو نیست بلکه یک اقدام است. در مورد آزمایش زمانی که مشتری به دلایلی با موفقیت اضافه نشده است، یا زمانی که آنها اضافه شده اند اما از قبل وجود دارند، چطور؟
همچنین چه زمانی اضافه می شوند؟ برای مثال، می‌توانید نام آزمایش را: WhenCustomerHasFullName_CustomerAddedSuccessfully. در اینجا تستی وجود دارد که سناریویی را آزمایش می کند که چه زمانی نام کامل مشتری در پست درج شده است. این نام شامل سناریوی “وقتی نام کامل مشتری وارد می شود” و انتظار می رود: “مشتری با موفقیت اضافه شد”.
گنجاندن سناریو بخش مهمی از نام آزمون شما است. شرایط عملی که انجام می دهید را توضیح می دهد. “وقتی این کار را انجام می دهم”. “وقتی این داده ها گنجانده شود”. “وقتی سعی می کنم به عنوان یک مدیر به این دسترسی داشته باشم”.
انتظار نتیجه مورد انتظار شماست. نتیجه آزمون. این به اندازه سناریو بسیار مهم است. آنها با هم ترکیبی را تشکیل می دهند که دلیل وجود آزمون را توضیح می دهد. “وقتی این اتفاق می افتد، باید این اتفاق بیفتد.”
ممکن است برخی از شما از الگوی “SystemUnderTest_When_Then” برای نامگذاری تست ها آگاه باشید. این خوب است، و من این ساختار را توصیه می کنم، اما فقط به این دلیل که شامل سناریو و انتظارات است. سیستم در حال آزمایش، یا چیزی که شما در حال آزمایش آن هستید، البته توصیفی و مفید است، اما با نگاه کردن به کد به راحتی می توان آن را استنباط کرد (برخلاف سناریو؛ و معمولاً انتظارات را می توان به راحتی از ادعاها به دست آورد) و همچنین ، می توانید این را در نام کلاس، برچسب ها یا برخی توصیفگرهای دیگر قرار دهید.
این است سناریو و انتظار که هر کسی که به تست ها نگاه می کند می خواهد بداند. اینها بخشهای مهم نام یک آزمون هستند.
درست بودن این موضوع نه تنها به این معنی است که آزمون‌های شما به راحتی قابل پیگیری و درک هستند، بلکه شما را تشویق می‌کند تا ترکیب‌های بیشتری را در نظر بگیرید. می‌توانید این ترکیب‌های سناریو/انتظارات را قبل از اینکه تست‌ها را کامل کنید، بنویسید. اگر بخواهید نام آزمایشی را «GetTimeZoneTest» یا «FileProcessorTest» بگذارید، چگونه این کار را انجام می دهید؟
همچنین شایان ذکر است که می‌توانید هر آنچه را که در اینجا در مورد آن صحبت می‌کنم، در «ویژگی‌های توصیف» یا «موردهای آزمایشی»، در صورت ترجیح، به جای نام آزمون اضافه کنید. نکته این است که مشخص است آزمایش ها چه می کنند.
با گنجاندن سناریو و انتظارات در نام‌ها/توضیحات آزمون، شما را تشویق می‌کند که مانند یک آزمایش‌کننده فکر کنید. نگران خواهید شد چرا شما در حال نوشتن تست ها هستید و یاد می گیرید که سناریوها را با انتظارات مرتبط کنید.
همچنین خواندن تست های شما را آسان می کند و اسناد مفیدی را برای نگهبانان آینده تشکیل می دهد.
