معرفی انواع تست فرانت اند

تو این مقاله قصد دارم معرفی کلی در مورد انواع تست نویسی فرانت اند (و عموما سایت) داشته باشم. تست نویسی فرانت کار راحتی است که با اجرای درستش میتونید جلوی خیلی از اضافه کاری هارو در آینده بگیرید. این که چه تست های برای سایتمون لازمه سوالی هست که دلیل نوشتن این مقاله من شده.

وقتی اولین بار تو گوگل راجع به تست نویسی فرانت جستوجو میکنید به نتیجه درستی حسابی نمیرسید. آموزش های خیلی جامعی در این مورد وجود نداره. متاسفانه اکثر شرکت ها هم برای کاهش هزینه های فعلی و رفع بار مسئولیت و همچنین تحویل زودتر پروژه دست به حذف فرآیند تست نویسی میزنند.

یک جمله خیلی معروف در مورد تست نویسی وجود داره :
کدی که تست نداره یعنی کامل نشده.

درسته که وقت گذاشتن برای نوشتن تست در واقع خروجی بصری برای مدیران پروژه نداره اما مزیت های بیشماری داره که در آینده بیشتر در موردش صحبت میکنم.

فرآیند تست نویسی دنیای بزرگی داره و ازون جا که قرار نیست من به همه ابعادش اشاره داشته باشم به ساده ترین و خلاصه ترین شیوه ممکن این مقاله رو نوشتم. درآینده مقاله های تکمیلی در این مورد ارائه میدم.

تو این مقاله قصد دارم به این سوال جواب بدم که اصلا سمت کلاینت ( مثلا سایت ) چه چیزهایی رو باید تست کنیم ؟‌

این آموزش رو با یک مثال پیش میبرم. این صفحه لاگین رو در نظر بگیرید:

از یک المان هدر برای نمایش تایتل استفاده شده و ۲ المان ورودی که یکی نام کاربری و یکی رمز ورود رو از کاربر میگیره

یک دکمه برای لاگین کردن و یک لینک برای اینکه اگر رمز عبور رو فراموش کردید به صفحه مربوطه برید و ...

اینو هم در نظر بگیرید که اگر رمز عبور و یا نام کاربری صحیح نباشه ، پیغامی به کاربر نمایش داده میشه

خب برای این صفحه چه تستی هایی میشه نوشت ؟

تست هایی که استفاده میکنیم به چند دسته کلی تقسیم میشن، اینجا مهمترین و پر کاربردترین هاشو بررسی میکنم:

۱ - تست ساختاری

که ترجمه structural testing هست و وظیفه چک کردن ساختار مارو داره. این سبک تست به نحوه نوشتن کد شما کاری نداره و قراره اجزای صفحه رو چک کنه. یعنی اینکه چک کنه:

یک هدر وجود داشته باشه (یعنی هدر به درستی نمایش داده میشه)

دوتا فیلد ورودی وجود داشته باشه

یک دکمه با عنوان مناسب وجود داشته باشه

و لینکی در انتهای صفحه موجود باشه

نمایش خطای مناسب ( در صورت اشتباه وارد کردن مشخصات حساب )

این سبک تست هارو با کتابخونه Enzyme و همچنین مدل تست نویسی Snapshot کنترل میکنن.

۲ - تست واکنش‌ها

که ترجمه Interaction testing میباشد. این تست درواقع برخورد سایت ما با کاربر رو در نظر میگیره. توی مثالی که گفتم یک دکمه وجود داره و دوتا فیلد که کاربر میتونه بعد از کامل کردن اونها روی دکمه ورود کلیک کنه. چیزایی که باید در نظر بگیریم:

تست کنیم اگر کاربر روی دکمه ورود کلیلک کرد (درصورتی که اطلاعات ورودی صحیح بود) به صفحه بعدی منتقل شود و در صورتی که داده ها همخونی با داده های سرور نداشت پیامی شامل خطا به کاربر نمایش دهد.

تو همین صفحه یه لینک برای فراموشی رمز عبور هم قرار گرفته که میشه به این شکل بهش نگاه کرد:
درصورتی که کاربر روی لینک مورد نظر کلیلک کرد باید به صفحه جدیدی منتقل شه.

۳- تست استایل

همونطور که از اسمش مشخص هست ،‌این سبک تست ها وظیفه این رو دارن که استایل سایت مارو چک کنن. فرض کنید ما میخواهیم استایل صفحه رو تغییر بدیم و یا اینکه ری فکتور انجام بدیم و توقع داریم خروجی همون خروجی قبلی باشه. این سبک تست نوشتن با سبک snapshot هم قابل انجام است.

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

۴- تست بصری

که همیشه توسط کاربر انجام میشه و بعد از انجام فرآیند های مختلف، خود توسعه دهنده ( و یا تیم مدیریتی و کنترل کیفیت ) اقدام به تست صفحه مورد نظر میکنند و همه اجزای اون رو بررسی میکنند.

این سبک تست های بصری به صورت دستی و غیر اتوماتیک انجام میگیره و از دید خود کاربر هست که داره سایت رو بررسی میکنه.

نتیجه گیری

تو این مقاله در مورد اینکه چرا باید تست بنویسیم و لزومش چی هست بحثی نکردم و صرفا انواع تست نویسی های سمت فرانت رو بررسی کردم.

تست های اول تا سوم که با استفاده از کدها انجام میشه. روش چهارم تست بصری که در نهایت انجام میشه ولی ۳ تست قبلی در واقع خود کدهای ما هستن دارن کدهامون رو تست میکنن!

فرض کنید این ۳ سبک تست رو برای صفحه لاگین که مثال زدم نوشته باشیم. حالا تو صفحه دیگه ای میخواهیم از این لاگین استفاده کنیم و یا اینکه میخواهیم کدهایی که برای تولید صفحه لاگین زدیم رو reformat کنیم. خوب بدون تست باید تک تک ارتباطاتمون رو چک کنیم همچنین نحوه برخورد با رمز عبور اشتباه و ...
فرض کنید یه reformat ساده کرده باشید اما مجبورید برای اینکه مشکلی پیش نیاد همه روندهای جاری رو تست کنید و مطمئن شید که کارایی کدتون تغییری نکرده.

حالا همین موضوع رو با شرایطی که تست های مناسبی نوشتیم در نظر بگیرید. بعد از انجام تغییرات و reformat و ... کافیه که یکبار تست ها رو ران کنیم.
در صورتی که تست های مناسبی نوشته باشیم میتونیم با خیال راحت از اینکه تغییرات جدیدمون آسیبی به عملکرد کدهامون نزده ، کارمون رو تموم کنیم.

این همه دلیل و منطق برای استفاده از تست نویسی نیست اما از ویژگی اصلی تست نویسی میشه به همین مورد اشاره کرد.

ممنون از اینکه با من همراه بودید.

سایر مقاله های من در ویرگول:

Contact With me:

https://t.me/nimamohamadian
https://www.facebook.com/nimamohamadian89
https://twitter.com/Nima_Mohamadian
https://www.linkedin.com/in/nima-mohamadian-57ba63123