سلام و درود خدمت همه ی دوستان
در این نوشته سعی دارم مطالبی رو راجع به یکی از Test Smell ها به نام Obscure test بنویسم.سعی میکنم در متن عکس هایی رو از منبعی که دارم مطالعه میکنم قرار بدم و فهم خودم رو از کتاب بنویسم
منبع:کتاب xUnit Test Patterns از Gerard Meszaros
تعریف:
وقتی تستی که نوشتیم با یک نگاه قابل فهم نباشد و برای خواندن و فهمیدن آن باید تلاش زیادی انجام بشود
میشود از این test smell به عنوان تست پیچیده یا تست طولانی هم نام برد
دوتا فاکتور خیلی مهم Readability و Maintainability را برای نوشتن تست ها داریم
این Test smell باعث میشود که تست ها Readable نباشند و در ادامه باعث میشود که ما در نگهداری تست ها هم مشکل داشته باشیم و نتوانیم به یکی از اهداف Test Automation که رسیدن به Test as Documentation هست،برسیم
منظور از Test as Documentation این است که تست های ما اگر خوب Design بشوند و اصولی نوشته بشوند، یک Document خیلی خوب برای پروژه محسوب میشوند.
بررسی دلایل Obscure Test
1_Eager Test
تعریف:وقتی یک تست، حالت ها و شرط ها و سناریوهای مختلفی را بررسی میکند
هر یونیت تست ما باید یک شرط و یک حالت از سناریو مد نظر Sut مارا بررسی کند
2_Mystery Guest
وقتی که تست را میخوانیم یک Logic و یک منطق بین دو مرحله Fixture Setup و Verification پنهان شده است که در نگاه اول نمیشه آن را فهمید و فهمیدنش سخت است
برای فهم بهتر به کد زیر که مثال خود کتاب هست نگاه کنیم
در این تکه کد در قسمت Fixture setup یک فایل Csv در ابتدا Load شده است
سپس تست Exercise شده است
بعد در قسمت Verify یک سری منطق با استفاده از همان فایل csv چک شده است که فهمیدنش سخت است
در واقع تاثیر آن فایل csv در نتیجه تست پنهان است و فهمیدنش سخت است.
3_General Fixture
گاهی اوقات به دلیل اینکه کد کمتری داشته باشیم یک Fixture setup خیلی کلی مینویسیم و آن را در سناریوهای مختلف استفاده میکنیم
این کار باعث میشود درک و فهمیدن برخی سناریوها پیچیده شود
مثلا فرض کنید یک Builder خیلی کلی برای یک موجودیت در برنامه به اسم Product نوشتیم و آن را درتمامی سناریوهای مربوط به Product استفاده کردیم.
فرض کنید که مثلا در یک سناریو خاص حتما نیاز داریم که کسی به عنوان خریدار این محصول در سناریو نقش آفرینی کند. اگر ما بیایم و از همان Builder خیلی کلی استفاده کنیم، این مورد که حتما باید فردی به عنوان خریدار در سناریو حضور داشته باشد،در بخشی از کلاس Product و آن Builder پنهان میشود و باعث میشود خوانایی تست پایین بیاید و فهم آن در نگاه اول سخت باشد
برای این کار میتوانیم از builder های اختصاصی تر و جزئی تر استفاده کنیم تا تست خوانا باشد به عنوان مثال شبه کد زیر
ProductBuilder.Build().SetBuyer(somePerson)
ابتدا یک محصول را میسازد و سپس فردی را به عنوان خریدار set میکند که این کار به خوانایی کد کمک میکند
4_Irrelevent Information
وقتی رخ میدهد که برای یک سناریوی خاص دیتاهای اضافی را در قسمت Fixture setup مهیا کنیم .
دیتاهایی که برای آن سناریو خاص اضافی هستند و در نگاه اول باعث گیج شدن و کج فهمی ما بشوند
برای مثال مثلا در یک سناریو نیازی نداریم که حتما خریدار برای یک محصول set بشود اما ما این کار رو انجام میدهیم و باعث میشود بعدا در خواندن تست دچار مشکل بشویم و فهمیدن رابطه بین Fixture setup و verification برای ما سخت بشود
یا مثلا تکه کد زیر که از کتاب انتخاب شده، اطلاعات اضافی در قسمت Fixture setup دارد که در سناریو تست مورد استفاده نیست
ممنون از اینکه برای خوندن این متن وقت گذاشتید و امیدوارم براتون مفید بوده باشه
این متن صرفا برداشت من از بحث obscure test هست و احتمالا نکات تکمیلی و اصلاحیه هایی خواهد داشت که خوشحال میشم اگر نظری و یا نکته ای هست برام بنویسید
