https://virgool.io/feed/@miadabrin من میعاد ابرین هستم. ادمین سیستم و برنامه نویس سابقا هم بنیان گذار و مدیر فنی سایت سازیتو بودم و قبلش برنامه نویس سایت تخفیفان .دانشگاه هم برق و معماری کامپیوتر خوندم fa 2026-06-07 17:29:22 https://files.virgool.io/upload/users/11041/avatar/avatar.png?height=120&width=120 https://virgool.io/@miadabrin https://virgool.io/@miadabrin/%D9%85%D8%B5%D8%A7%D8%AD%D8%A8%D9%87-%D9%81%D9%86%DB%8C-%D8%AF%D8%B1-%DA%A9%D8%A7%D9%86%D8%A7%D8%AF%D8%A7-%D8%A8%D8%B9%D8%B6%DB%8C-%DA%86%DB%8C%D8%B2%D9%87%D8%A7%DB%8C%DB%8C-%DA%A9%D9%87-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%A8%D8%AF%D8%A7%D9%86%DB%8C%D8%AF-wubjqan4rgvt مصاحبه فنی در کانادااگر مهندس نرم افزار هستید و به فکر مهاجرت به کانادا هستید و یا مثل من تازه اینکارو کردید احتمالا این نوشته به دردتون میخوره. در ضمن تجربه من در ایالت اونتاریو بیشتر موضوعیت داره جاهای دیگه شاید کمی فرق بکنه.از آخر شروع کنیم! بعد از یه ماراتن دو هفته ای و بین کلی ریجکشن نهایتا از بین چند آفر خوب بهترین آفرم رو پذیرفتم و هفته دیگه دارم میرم سر کار جدیدم. ولی به نظرم اومد تجربش احتمالا خیلی به درد بقیه بخوره.دو هفته قبل که تازه اجازه کار پیدا کردم شروع کردم موقعیت های شغلی رو دیدن و اپلای کردن. اینم بگم که من خودمو فول استک میدونم و برای همین تقریبا تو همه ی پوزیشن های ممکن رزومه دادم. میشه حدس زد که همیشه جواب های دلخواهمو نگرفتم.میخوام در مورد مهمترین جزییات این فرآیند براتون بیشتر صحبت کنم. اول بریم سراغ اینکه چه تخصص هایی بیشتر تو این حوزه نیازه.تخصص هاچیزی که اول از همه متوجه شدم این بود که تخصص های مورد نیاز خیلی رنجش وسیع هست. سمت بک اند شرکت های بزرگتر به خاطر نرم افزار های قدیمی ترشون معمولا تاکیدشون روی جاوا و دات نت هست. شرکت های جدید هم معمولا NodeJs و گاها گولنگ. چیزی که خیلی برام جالب بود این بود که خیلی شرکت های کمی روبی کار میخواستن و پایتون هم محدود به شرکت هایی بود که کارشون ماشین لرنینگ و به طور کلی دیتا ساینس بود. در زمینه های c/c++ و کلا کارهای embedded که به وفور فرصت شغلی زیاد هست.سمت فرانت اند اما بیشتر همه داشتن طرف react و vue میرفتن. خیلی ها هم به خاطر استک فعلیشون angular میخواستن ولی چیزهای نایاب تر مثل meteor و ... اصلا روی بورس نبود. خیلی از شرکت ها دولوپر فرانت اند رو به عنوان طراح رابط کاربری میخواستن. یه سریا هم خوب به عنوان برنامه نویس میگرفتن. سمت دوآپس ولی چندان استقبال زیاد نبود. از این نظر که عنوان شغلی به این صورت system admin یا Devops Engineer وجود نداشت و اگر کسی اینارو لازم داشت با همون عنوان fullstack دولوپر دنبالش میگشت.البته بگم من دو هفتس اپلای میکنم ولی حدود ۴ ماهی هست که عنوان های شغلی رو بررسی میکنم برای همین داده هام چندان نادقیق نیست.فرآیند مصاحبهاینجا تقریبا تمام اتفاقات با ایمیل میفته. کسی به شما زنگ نمیزنه مگر اینکه ساعت مصاحبه از قبل هماهنگ شده باشه. اگر رزومتون تخصص های مورد نیاز اونها رو داشته باشه یه نفر از منابع انسانی باهاتون تماس میگیره و ازتون در مورد خودتون میپرسه. اسم این مرحله رو میذاریم مرحله آشنایی که در ادامه راجع بهش میگم. مرحله دوم بستگی به شرکتش داره. ولی اصولش اینه که اکثر شرکت ها به نوعی یک چالش اولیه مطرح میکنن که ببینن اینکاره هستید یا نه. این چالش میتونه در قالب یه مصاحبه آنلاین نیم ساعته تا یک ساعته باشه و یا به صورت یک تست آنلاین زمان دار. تقریبا در تمام موارد این مرحله زمان محدودی داره. اسم این مرحله رو میذاریم مرحله چالش اولیه و در موردش بیشتر حرف میزنیم.اینجا ولی مسیر شرکت ها از هم جدا میشه. یک سری از شرکت ها ازتون مستقیم برای مصاحبه دعوت میکنن و توی همون مصاحبه سر و تهشو به هم میارن. ولی شرکت های بزرگتر مصاحبه های مرحله ای ازتون میکنن. از صحبت های فنی با مدیر مستقیم تا چالش های فنی ریز و درشت که در مورد اون ها هم حرف میزنیم. اسم این مرحله رو میذاریم غول اصلی.مرحله بعدی مرحله پرسیدن رنج درخواستی هست که بسیار مساله مهمیه. اینو با جزییات بیشتری توضیح خواهم داد.مرحله آخر هم معمولا به صورت خلاصه شامل فرستادن آفر و قبول کردنش و مراحل بعد از اون یعنی رفرنس چک و بکگراند چک میشه. نکته ای که اینجا مهمه اینه که معمولا رفرنس چک و بک گراند چک بعد از پذیرفتن پیشنهاد انجام میشه که کارو یه مقدار سخت میکنه برای همین خوبه که به فکر رفرنس های خوب باشید. در مورد بک گراند چک و رفرنس چک هم بیشتر حرف میزنیم.مرحله آشناییتو این مرحله همونطوری که گفتم یک نفر باهاتون تماس میگیره و در مورد خودتون ازتون میپرسه چند تا نکته مهمی که به نظرم میرسه:شرکت مقابل رو خوب بشناسیدمعمولا اولین سوالی که طرف میپرسه اینه که چقدر اونارو میشناسید. قصد این سوال اینه که ببینن شما واقعا به نوع کار علاقه دارید یا همینطوری رزومه میفرستید تا یکیش بگیره. برای همین حتما و حتما وب سایت کمپانی مورد نظر رو زیر و رو کنید. ترجیحا آدمایی که اونجا کار میکنن رو هم بشناسید و کلا طوری رفتار کنید که انگار کلا فقط همین یه جا رزومه فرستادید.از شوآف کردن بپرهیزیدمعمولا کسی که با شما تماس گرفته بک گراند فنی قوی نداره. سعی کنید موارد فنی رو در سطح دانش عمومی مطرح کنید. مثلا اگر از شما پرسید یه مساله سختی که حل کردی بگو در مورد graph architecture ی که فلان جا پیاده سازی کردید نگید. بهش به صورت عمومی بگید چی سخت بود و راه حل شما برای حل کردنش به چه شکل بود.شوخی کنید و هیجان داشته باشیدشاید مسخره به نظر بیاد ولی این شخص اولین مرحله ماجراست و اگر از شما خوشش نیاد میتونید با شغل مورد نظر خداحافظی کنید. بنابراین سعی کنید لای حرفاتون چیز های با نمک و جذاب هم داشته باشید. تو مکالمه راحت باشید.در موردشون بپرسیدیکی از مهمترین مواردی که میتونه واقعا بهتون کمک کنه پرسیدن در مورد فرهنگ کاری شرکت و نوع کار کردن در محیط شرکته. ازشون ساختار تیم رو بپرسید. ازش بپرسید دقیقا چه نقشی رو ازتون خواهند خواست ایفا کنید و پروژه هایی که در دست دارن تو چه سبکیه. به این شکل طرف احساس میکنه کار برای شما واقعا مهمه.از گفتن مفاهیم به صورت انتزاعی بپرهیزیدمعمولا به عنوان شخص فنی شمارو استخدام میکنن که یک سری مشکلات فنی رو پوشش بدید برای همین سعی کنید تاکیدتون روی مهارت های فردی باشه. اگر در مورد مهارت های تیمیتون صحبت میکنید از گفتن واژه هایی مثل رهبری و انتقاد پذیر و ... بپرهیزید. سعی کنید اینارو اول برای خودتون به صورت فیزیکی ترجمه کنید و اون ترجمه رو بیان کنید جوری که نحوه ی تعاملتون رو با بقیه آدمها نشون بده.مرحله چالش اولیه این مرحله شامل اولین چالشی میشه که بهتون میدن. این چالش میتونه یکی از موارد زیر باشهمصاحبه تلفنی high-level که معمولا طرف در مورد روش حل مسایل خاص و تکنولوژی های استفاده شده توی شرکت هایی که در رزومه آوردید سوال میپرسه. این شخص معمولا مدیر فنی یا مدیر بخشه و معمولا از نحوه حرف زدنتون میفهمه چقدر با تکنولوژی های مورد نظر کار کردیدمصاحبه فنی آنلاین که معمولا شما با یک شخص دیگه لایو صحبت میکنید. یه مقدار از خودتون میپرسه و معمولا بلافاصله یه چالش فنی مطرح میکنه که شما تو یه محیط آنلاین حلش میکنید. چالش ها گاها خیلی سخت هستن و ممکنه نتونید کامل حل کنید. توصیه میکنم نحوه فکر کردنتون رو با طرف به اشتراک بذارید و اجازه بدید اون هم به نوبه خودش کمکتون کنه. تجربه من این بوده که این سوالات معمولا سوالات پایه ای هستند که وابسته به تکنولوژی خاصی نیستند. یک الگوریتم سورت به خصوص و یا یک چالش با جاوااسکریپت داخل مرورگر و یا طراحی یک بازی با هر زبونی که دوست داشتید.تست آنلاین که شما خودتون هستید فقط و زمان محدود دارید. میزان سختی تست کاملا بستگی به شرکت مورد نظر داره و باز هم بیشتر دانش های پایه ای رو هدف میگیرن. SQL و یا javascript و یا دانش regex و ...برای این مرحله تا حدود زیادی نیاز به تجربه و دانش همزمان دارید . چالش ها گاها چندان سخت نیستند ولی ممکنه محدودیت زمانی و اینکه با طرف مقابل هم باید وسطش صحبت کنید اذیتتون کنه. توصیه میکنم چند مثال رو بدون اینکه قبلش بدونید نوشتن مسایل به چه صورته با خودتون انجام بدید. مثلا الگوریتم های سورتینگ معمولی رو فقط با داشتن ایده به چند تا زبون محتلف بنویسید و یا سعی کنید یک بازی کوچیک طراحی کنید. تمرکزتون روی قدرت حل مساله باشه. همچنین بعضا ازتون میخوان کدهایی که بقیه نوشتن رو تحلیل کنید. این کار رو با خودتون چندین بار انجام بدید و اگر نمیتونید کتاب های طراحی و کد زیبا نوشتن خیلی میتونه کمک کنه.غول اصلیاین مرحله معمولا به صورت حضوری و احتمالا در چند مرحله انجام میشه. خودتون رو برای یک ماراتن فنی آماده کنید. مصاحبه های فنی ممکنه چندین مرحله داشته باشن و معمولا سوال های نسبتا سختی مطرح میشه که حالا یا ازتون میخوان کدش رو توی کامپیوتر خودتون بزنید یا روی تخته حل کنید. توصیه من همیشه روی تخته هست چون مجبور نیستید سینتکس ارور ها رو هم درست کنید.سوال های فنی مطرح شده معمولا شامل سوال های الگوریتمی و حل مساله های خاص میشه. مثلا پیدا کردن بازه خرید و فروش تو اطلاعات بورس یک روز و یا پیدا کردن یه روش بهینه برای برنامه ریزی یک روز خاص . همچنین سوال های طراحی و سطح بالاتر هم معمولا مطرح میشه که ببینن چقدر طراحی بلد هستید. نکته ای که مهمه که بدونید اینه که راه حل اولی که به ذهنتون میرسه معمولا بهترین راه نیست و ازتون میخوان جواب های بهتری پیدا کنید. سعی کنید تمرین کنید قبلش که مغزتون برای اینکار آماده باشه. در مورد اینکه چه چیزی در انتظارتون خواهد بود خیلی نمیشه پیش بینی کرد ولی معمولا تمرکز اصلی روی توانایی حل مساله و تحلیل شما و همچنین دانش بیسیک مهندسی نرم افزار هست. با تمرین میتونید خیلی نتایج خوبی بگیرید.پرسیدن رنج درخواستیرنج درخواستی خیلی مهمهدیر یا زود ازتون در مورد حقوق درخواستی سوالی میکنن. قبلش تو سایت های اشتغال مثل neuvoo.ca نسبت مهارت و رنجتون رو مشخص کنید. در واقع چیزی آن چنان به عنوان مذاکره برای حقوق نیست ( به جز موارد معدودی). از شما رنج درخواستی رو میپرسن. اگر بتونن بدن و شما رو لایقش بدونن توی همون رنج پیشنهاد میدن در غیر اینصورت براتون آرزوی خوشبختی و سعادت میکنن.آفر و بعد از آناگر خوش شانس باشید و مراحل بالا رو رد کنید آخرین مرحله براتون آفر ارسال میشه. این آفر معمولا زمان پایان نزدیکی داره ( بین یک روز تا ۴-۵ روز) و بعد از اون دیگه اعتباری نداره. نکته مهم اینه که پذیرفتن آفر معمولا برای شما تعهد ایجاد میکنه و اگر بزنید زیرش ازتون خسارت میگیرن. این شرکت به شرکت فرق میکنه ولی معمولا به این شکله. بعد از پذیرفتن آفر معمولا بکگراند چک میشید که سابقه ی خلاف ندارید و بعدش با افرادی که خودتون معرفی میکنید از همکاران و روسای سابق تماس میگیرن و اخلاق های کاری و مهارت های کاریتون رو ازشون میپرسن. نکته ای که مهمه اینه که سعی کنید رفرنس هاتون قابل اعتماد باشن چون از زمانی که آفر رو قبول میکنید تا زمانی که کامل بررسی بشه عملا آفر جای دیگه رو نمیتونید بپذیرید بنابراین سر این مرحله ریسک نکنید.نکته هایی که مونددر مورد رزومه نویسی خیلی مطلب هست. سعی کنید بخونید و رزومه ساده متنی بدون عکس و داستان اضافه داشته باشید. علتش هم این هست که خیلی از شرکت ها رزومه ها رو با ماشین بررسی میکنن و اگر ماشین رزومه رو نتونه بخونه عملا کارو از دست میدید.چندین سایت مختلف رو برای کار بررسی کنید. تو کانادا این چند تا سایت برای کار خیلی مهمن:indeed.calinkedin.comneuvoo.caworkintech.caglassdoor.caنا امید نشید. از بین این همه کار فقط یکیش رو هم بتونید بگیرید کافیه. کانادایی ها به شدت محتاط و کند هستن. ممکنه از زمانی که رزومه شما فرستاده تا دیده میشه یه بازه ۳ ۴ هفته ای طول بکشه.برای نوشتن رزومه و همچنین تکمیل پروفایلتون در سایت های کاریابی وقت بذارید. واقعا کار زمان بر و حوصله سر بری هست ولی در موفقیت شما بسیار موثره. تمامی اطلاعاتتون رو یکسان و هماهنگ بذارید تا یک چهره واحد از خودتون نمایش بدید.اگر سوالی داشتید برام در توییتر بفرستید که در حد توانم کمک کنم. به امید روزی که خارجی ها برای کار کردن در ایران چنین پستی بنویسند. Miad Abrin Miad Abrin Thu, 18 Apr 2019 05:36:51 +0430 https://virgool.io/@miadabrin/%DA%86%D8%B7%D9%88%D8%B1-%D8%B9%D9%84%D9%85%DB%8C-%D9%88-%D8%A7%D8%B5%D9%88%D9%84%DB%8C-%D8%AA%D8%B3%D8%AA-%D8%A8%D9%86%D9%88%DB%8C%D8%B3%DB%8C%D9%85-i1jpqgmcqewz تمامی اصولی که در این نوشتار آمده یک جور هایی بر اساس علم تست که در واقع سخت افزاری ها اون رو بسط و گسترش دادن نوشته شده. سخت افزاری ها از اون جایی که فرصت کمتری نسبت به نرم افزاری ها برای جبران اشتباهاتشون دارن، بهتر تست می کنند تا از عملکرد مدارات اطمینان حاصل کنن.چرا اصلا تست بنویسیمشاید برای شما که این مطلب رو مطالعه میکنید، کاملا جواب این سوال بدیهی باشه. هدف از تست نوشتن اطمینان پیدا کردن از عملکرد صحیح نرم افزار طراحی شده است وقتی که کاملا واقف هستیم که کد نوشته شده گسترش و یا تغییر پیدا خواهد کرد.اگر قبلا نرم افزاری نوشته باشید که تست براش نوشته نشده حتما متوجه شدید که هر بار آپدیت کردن نرم افزار شما رو به استرس میندازه چون مشخص نیست که آیا کد جدید به خوبی کد قبلی کار میکنه یا خیر.همچنین در صورتی که تست ننویسید اصولا از وجود یک سری ایرادات مطلع نمیشید. علتش هم این هست که معمولا وقتی به صورت دستی چیزی رو تست میکنیم فقط مسیر کارکرد اصلی رو بررسی میکنیم و مسیر های انحرافی و غیر سر راست بررسی نمیشن.مشکل کجاستاگر شروع به تست نوشتن کرده باشید کم کم این مساله که چقدر باید تست نوشت یا به چه شکلی نوشت و یا اصولا چه چیزی رو تست کرد براتون به صورت چالش در خواهد اومد. تست نویسی خود در واقع به همراه دانش دیگه ای معنی پیدا میکنه که اسم اون کد نویسی تست پذیر هست. به عبارت دیگه کد اصلی رو هم جوری بنویسیم که بشه اون رو تست کرد. برای اینکه به صورت پایه ای تر و اصولی تر این بحث رو دنبال کنیم ابتدا یک سری مفاهیم رو معرفی میکنیم:ایراد یا فالتیک ایراد یا فالت عبارت است از وجود یک مشکل در بخشی از کد که منجر به ایجاد مشکل در روند نرم افزار شود. به هنگام تست نویسی ما فالت های مختلف ایجاد میکنیم و مطمین می شویم که تاثیرات غیر قابل قبول در کد ایجاد نمی کنند.معادل سازی فالت هاوقتی دو فالت در عمل با یک تست شناسایی می شوند این فالت ها معادل هستند. مثلا فرض کنید ما با نوشتن یک تست هم ایراد موجود در جست و جو را پیدا میکنیم و هم همان تست میتواند ایراد موجود در مرتب سازی را به ما نمایش دهد. در این حالت همین یک تست برای هر دوی آنها کافیست و در واقع این دو فالت معادل هستند.برتری فالت هافرض کنید با نوشتن تست برای یک فالت خاص ، وجود یک فالت دیگر پیدا شود. بنابراین ما نیازی به نوشتن تست جداگانه برای آن فالت نداریم و به اصطلاح فالت دوم بر فالت اول برتری دارد و خود به خود در نظر گرفته نمی شود.کنترل پذیریاین واژه به معنای میزان توانایی ما به تغییر دادن یک حالت داخلی با استفاده از تغییر دادن ورودی است. یعنی این که چقدر برای ما سخت هست که وضعیت داخلی یک برنامه رو با عوض کردن ورودی عوض کنیم و در واقع تاثیر تغییر ورودی رو ببینیم. این پارامتر در مهندسی تست در گرایش سخت افزار به صورت یک عدد برای مکان های مختلف موجود در یک مدار تعریف میشه. جاهایی که عدد بالاتری دارند یعنی برای تست آنها چالش بیشتری خواهیم داشت.اما در مهندسی نرم افزار این عدد بیشتر یک عدد حسی و کیفی است. اگر منطقه ای از کد توسط ورودی های اولیه به راحتی عوض نمی شود یعنی آن نقطه از کد برای تست شدن ما را با چالش مواجه میکند.مشاهده پذیریاین پارامتر نشون دهنده این هست که با دیدن یک نتیجه آیا میتوان ورودی ها و یا وضعیت داخلی پارامتر های موجود در کد را شناسایی کرد و یا خیر. در واقع هر چقدر اجزای مختلف کد مشاهده پذیری کمتری داشته باشند پیدا کردن ایرادات و یا باگ ها در آن سخت تر است.استیت یا حالتاستیت یا حالت در واقع عبارت است از وضعیت فعلی نرم افزار. یعنی وضعیت تمام داده ها، متغیر های گلوبال و ... اصولا تمام کد هایی که ما مینویسیم برای ایجاد یک حالت و سپس نشون دادن اون حالت به کاربر هست و نه چیز دیگه. بنابراین نحوه تغییر کردن این وضعیت در تست نویسی بسیار مهم هست.بازتولید پذیریاین مفهوم در واقع بیان کننده این هست که آیا میتوان تست های مورد نظر را دقیقا با شرایط پیشین دوباره ایجاد کرد؟ در واقع آیا کد ما وابسته به پارامتر هایی خارج از منطق خود کد هست و یا خیر.اسکوپ یا موضوعیتمشخص میکند که این تست در چه لایه ای انجام میشود. مثلا آیا ما یک کارکرد خاص را تست میکنیم و یا یک سناریوی نوشته شده در نرم افزارمون رو تست میکنیم. مثلا در این رابطه تست های یونیت ( تست هایی که یک کارکرد خاص را تست میکنند ) و یا تست های اینتگریشن ( که یک سناریوی خاص را تست میکند) حایز اهمیت هستند.حال که با این مفاهیم آشنا شدیم ابزار لازم برای شروع بحث را داریم. حال با نگاه کاربردی به سراغ مساله تست میرویم:اصولا چه چیز را تست کنیماین سوال مهمترین مساله در تست نویسی است. اگر در نظر دارید که برای همه چیز تست بنویسید باید به جرات بگویم که وقتتان را تلف میکنید! در واقع تست نویسی بیش از حد و تست مواردی که نیازی به تست ندارند فقط پروسه تولید نرم افزار را طولانی میکنند و نگه داری کد و تغییر آن را مشکل تر میکنن. پس بگذارید اول بررسی کنیم که چه چیزی را تست نکنیم!جواب این سوال با دانستن فلسفه تست نوشتن به راحتی به دست می آید. ما تست مینویسیم که از کارکرد نرم افزار خود اطمینان داشته باشیم و بنابراین اگر تستی که مینویسیم کمکی به این امر نمی کند ننوشتن آن تست بهتر از نوشتن آن است. در واقع ما فقط چیز هایی را تست میکنیم که نیاز داریم از کارکرد آنها اطمینان حاصل کنیم. بنابراین اگر کدی ساده است و کارکرد خاصی ندارد نیازی به تست آن نیست. بیایید با یک مثال شروع کنیم تا در قالب آن مثال موضوع را بهتر بررسی کنیم. فرض کنید میخواهیم یک واسط برای گرفتن محصولات یک فروشگاه بنویسیم. مثلا فرض کنیم قرار است آدرس آن به این صورت باشد:/api/productsاین آدرس قرار است پاسخ های متفاوتی به کاربر عادی و ادمین فروشگاه بدهد. همچنین قرار است یک سری پارامتر از جمله فیلتر های مختلف و نحوه مرتب سازی را از کاربر بگیرد و محصولات مورد نظر را به صورت صفحه بندی شده نمایش دهد.قبل از اینکه ادامه را بخوانید فکر کنید که اگر میخواستید این واسط را طراحی کنید و آنرا تست کنید چطور عمل میکردید.این واسط چندین بخش مختلف دارد که آنها را به ترتیب مینویسیم:بررسی اینکه چه کاربری دارد به این واسط درخواست میدهد.بررسی اینکه آیا پارامتر های کاربر صحیح هستند یا خیرتبدیل پارامتر های کاربر به پارامتر های سرچ و مرتب سازی برای دیتابیس با توجه به نوع کاربرگرفتن نتایج از دیتابیس و تبدیل آنها به یک پیغام قابل دیدن برای کاربرارسال به کاربر.حال فرض کنید این مراحل را نوشته ایم و در حال تست کردن کارکرد این واسط هستیم. اولین نکته ای که حتما به آن توجه کرده اید تست کردن تمام سناریو های ممکن دریافت پاسخ توسط کاربر کاری بسیار زمان بر خواهد بود. بر فرض اینکه ما ۵ فیلتر مختلف، ۳ روش مرتب سازی مختلف، ۵ نوع کاربر مختلف و صحه بندی های مختلف داشته باشیم حداقل نیاز داریم که ۱۰۰ تست بنویسیم که تمام حالات را تست کنیم.مشخص است که ما توان و وقت اینکار را نداریم و بنابراین نیاز است که تست ها را هوشمندانه بنویسیم. و همچنین کد را به چند بخش auth برای بررسی کاربر، validate برای بررسی ورودی ها، logic برای قسمت ایجاد فیلتر ها و نیز گرفتن نتایج از دیتابیس و بخش presentation تقسیم کنیم.حال بهترین کار این است که تست ها را با توجه به اسکوپ مراحل مختلف بنویسیم:مثلا۱-تست هایی فقط برای بررسی نوع کاربر و اضافه شدن فیلتر های مناسب آنها به لیست فیلتر ها۲-تست هایی فقط برای بررسی ورودی کاربر۳-تست هایی برای بررسی صحت عملکرد هر کدام از فیلتر ها به صورت جداگانه۴-تست هایی برای بررسی عملکرد مرتب سازی۵-تست های برای اطمینان از صحت خروجیاز مراحل بالا مرحله ۱ - ۴ به صورت تست های ساده unit میتوانند نوشته شوند و فقط نیاز به یک یا دو تست برای دادن ورودی به صورت کامل و گرفتن خروجی و اطمینان از صحت خروجی نیاز داریم.در واقع برای بررسی منطق های پیچیده نیاز داریم تست را به ماژول های جداگانه تقسیم و جداگانه آنها را تست کنیم و سپس چند تست برای برای اطمینان از اتصال صحیح این ماژول ها داشته باشیم.دقت کنیم که تست نوشتن به این صورت در صورتی که تجربه کافی داشته باشید بسیار سریع تر از امتحان ورودی ها به صورت دستی است! و در واقع زمان توسعه نرم افزار را به شدت کاهش میدهد.در نوشتن تست های یونیت حتما مد نظر داشته باشید که این تست ها باید به صورتی باشند که به سادگی باز آفرینی شوند و نیز تاثیر جانبی ایجاد نکنند.برای اینکار نیاز داریم کد را به صورتی بنویسیم که موجودیت هایی که قوانین بالا را به هم میزنند را به صورت خارجی به ماژول خود بدهیم ( در خود ماژول این موجودیت ها به صورت مستقیم استفاده نشوند). مثلا چیزهایی مانند گرفتن زمان سیستم نباید داخل خود ماژول مورد بررسی از سیستم گرفته شود. بلکه باید به صورت پارامتر به ماژول داده شود ( مثلا به صورت یک اینترفیس که این اینترفیس زمان را به ماژول میدهد) . اینکار باعث می شود که به هنگام تست ما یک پیاده سازی ساده و ثابت را به این ماژول بدهیم ( مثلا یک زمان ثابت) و عملکرد مختلف ماژول رو بر اساس آن تست کنیم. همچنین کد هایی که ساید افکت ایجاد میکنند میتوانند به صورت فانکشن به ماژول اصلی داده شوند که باز هم به هنگام تست ما یک سری فانکشن بسیار ساده به جای آنها جایگزین کنیم که از صحت اجرا شدن آنها اطمینان حاصل کنیم.به این روش به اصطلاح IOC یا inversion of control می گویند که علت این نام گذاری این است که کنترل این موارد به خارج از ماژول ما منتقل می شود.دقت کنید که با اینکار می میتوانیم مطمین شویم که ماژول مورد بحث درست عمل میکند. در واقع اینکه عملکرد متدهایی که ساید افکت ایجاد میکنند و یا وضعیت غیر قابل پیش بینی ایجاد میکنند هیچ ربطی به ماژول فعلی ندارد و ماژول فعلی صرفا یک مصرف کننده این متد ها است و عملکرد این متد ها باید به صورت جداگانه در ماژول مربوط به خودشان تست شود.نکاتی بسایر مهم در رابطه با تست نوشتنبه هنگام تست نوشتن و نیز طراحی خود کد اصلی باید مطمین شویم که میزان کنترل پذیری و مشاهده پذیری بالاست . اگر این عدد پایین است نشان می دهد که موضوعیت یا اسکوپ تست ما بیش از اندازه بزرگ است و لازم است که ماژولهای ما بیشتر و مناسب تر تقسیم بندی شود.همچنین باید مطمین شویم که تست ها کاملا مستقل هستند و شرایط مورد نیاز تست قبل از اجرای آن فراهم می شود. مثلا در صورتیکه یک تست تکی بدون مشکل پاس می شود ولی به هنگامی که با بقیه تست ها اجرا می شود خطا می دهد، یعنی تست ها به یکدیگر وابستگی دارند.به هنگام تست نوشتن نسبت به کد خود بی رحم باشید! تست ها نباید به آسانی سبز شوند! در غیر این صورت این تست ها ارزشی ندارند. وظیفه تست دادن چراغ سبز و خوشحال کردن شما نیست. شما باید تمامی حالاتی که کد شما ممکن است بد عمل کند را شناسایی کنید و درست نوشتن تست به این صورت به میزان زیادی تجربه نیاز دارد. ولی وسواس به خرج ندهید و در هر صورت مناسب ترین و بهینه ترین تست هایی را که میتوانید بنویسید. دقت کنید که فقط مسیر های معمولی را تست نکنید و تمام مسیر هایی که ممکن است کاربر طی کند را باید در نظر بگیرید.پیاده سازی داخلی را تست نکنید! نحوه کارکرد داخلی یک ماژول ربطی به تست ندارد و وظیفه تست اطمینان از ورودی و خروجی های مختلف است.فالت های معادل را با تست های یکسان شناسایی کنید و تست اضافی ننویسید. دقت کنید که نیازی نیست که دقیقا همه چیز را تست کنید. فقط تا جایی تست بنویسید که از عملکرد اطمینان حاصل کنید.وقتی تست بنویسید که طراحی را تمام کرده اید. نوشتن تست وقتی که هنوز طراحی تمام نشده وقت تلف کردن است چون به همراه تغییرات زیاد باید تست ها هم عوض شوند.سرویس های خارجی را تست نکنید اگر ماژول شما به منابع خارجی نیاز دارد آنها را تقلید کنید.به هنگام تست خودتان بدانید چه چیز را تست می کنید و فقط یک چیز را تست کنید. یعنی وظیفه تست را از قبل مشخص کنید و اگر حس میکنید بیش از اندازه در تست خود چیز های مختلف را بررسی کرده اید دوباره به نحوه تست نوشتن خود فکر کنید و اگر نیاز است مسایل مختلف را جداگانه تست کنید.تست های خودتان را دسته بندی کنید که بعدا بتوانید تعداد خاصی از آنها را اجرا کنید. با مرور زمان معمولا اجرا کردن تمام تست ها با هر بار تغییر کد زمان بر می شود و شما باید بتوانید یک تعداد تست خاص را جداگانه اجرا کنید.دقت کنید که وظیفه برنامه شما ایجاد ساید افکت و تغییر استیت است! ولی وقتی کد مینویسید دقت کنید که هر ماژول فقط نسبت به عملکرد و وضعیت خود مسول باشد و نه بیشتر از آن. اگر چیزی از سیستم، شبکه، سرویس خارجی، دیتابیس و ... میگیرید یا قبل از تست آنها را آماده کنید ( مثل دیتابیس) و مطمین شوید آماده سازی اینها در صورتیکه کار ماژول شما صرفا استفاده از این موارد است توسط ماژول شما انجام نمیشود.به عبارت دیگر از هارد کد کردن یک نوع پیاده سازی خاص بپرهیزید، سعی کنید ماژول شما از اینترفیس ها به جای پیاده سازی اصلی استفاده کند که به هنگام تست بتوانید آنها را با چیزهای ساده عوض کنید. همچنین در صورتیکه ماژول شما یک تاثیر خارجی را فراخوانی میکند این تاثیر را به صورت فانکشن به ماژول بدهید که باز هم به هنگام تست بتوانید آنرا عوض کنید. دقت کنید که در هر صورت این ماژول در کد اصلی همان وظایف قبلی را دارد ولی عملکرد آن میتواند به این صورت جداگانه تست شود.کلام آخرتست بنویسید ولی زیاد نه! اگر دستتون تو کدنویسی پر هست و تست نوشتن شمارو از حالت معمولی کندتر میکنه معنیش اینه که دوباره باید به تست نوشتنتون فکر کنید. منطق های پیچیده رو در ماژول های خودشون به صورت محلی تست کنید و تست های اینتگریشن فقط برای مطمین شدن از وصل شدن صحیح ماژول ها به هم استفاده شود.اگر سوالی در این رابطه دارید میتونید تو توییتر از من بپرسید. خوشحال میشم پاسختون رو بدم. و اینکه نظراتتون برای من خیلی ارزشمنده. خوشحال میشم نظر بدید. Miad Abrin Miad Abrin Sat, 16 Jun 2018 20:34:22 +0430