گاها دیدم و شنیدم که بعد از دولوپ فیچر، تست انجام نمیشه و فیچر میره برای تست توسط مسئول تست، چرا؟ چون میگن خوب وظیفه ی ما نیست که تستش کنیم دیگه مسئول داره. یا اینکه ممکنه یه جایی از برنامه رو دست بزنیم یه جای دیگه به مشکل بخوره، و گفته شده: همه رو که نمیتونیم ما تست کنیم!
خب نکته اول اینه که فیچری که از سمت ما میره سمت واحد بعدیمون نباید باگ داشته باشه :) پس اگر مطمئن نیستی و اونجا باگ پیدا شد نباید بگیم که دیگه همینه دیگه باگ واسه نرم افزاره، باید حرفه ای تر عمل کنیم و جلوی باگ رو بگیریم.
همه ی اینا مقدمه ای بود که بتونم در مورد تست نویسی صحبت کنم. چرا تست مینویسیم و چطور تست بنویسیم.
خب اصلا تست نویسی چیه؟ به طور خلاصه، تست نویسی یکسری کدهایی هست، اضافه بر کد های اصلی نرم افزار، که در بخش های خاص مینویسیم تا بتونیم هر بخش از کد اصلی نرم افزار رو تست کنیم. مثلا اگر یک کلاس ولیدیشن داریم و یک فانکشن ولیدیشن شماره تماس، میتونیم حالت های مختلف ورودی رو به این فانکشن بدیم و ازش انتظار خروجی متناسب با ورودی هایی که وارد کردیم داشته باشیم.
حالا که به زبان ساده در مورد تست نویسی صحبت کردیم میتونیم در مورد چرایی تست نویسی هم صحبت کنیم... .
با نوشتن تست های مختلف و قبل از کدنویسی (TDD)، حالت های مختلف را در نظر میگیریم و از تست نشدن یک تحلیل خاص جلوگیری میکنیم. مثلا فرض کنیم برای تابعی که قرار هست یک شماره موبایل بگیره و ولید بودن شماره موبایل رو تشخصی بده میخواهیم تست بنویسیم، چندین سناریو مختلف میتونه برای تست بشه یعنی میتونیم ورودی های مختلف به فانکشن بدیم و خروجی ای که انتظارش رو داریم رو هم مشخص کنیم.
مثلا:
۱- شماره تلفن با ۰ وارد شده باشد.
۲- شماره تلفن با + وارد شده باشد.
۳- شماره تلفن با ۰۰ وارد شده باشد.
۴- شماره تلفن null وارد شده باشد.
۵- شماره تلفن رشته خالی وارد شده باشد.
۶- شماره تلفن کمتر ۱۱ رقم باشد.
و...
تابع ما با توجه به نوع نوشته شدنش میتونه به هر کدام از سناریو ها واکنش مناسب نشان بده. و چون میخواهیم تست های مختلفی رو بنویسیم، به طور کامل داریم به تحلیل کدمون میپردازیم.
تا داره کار میکنه تغییرش نده! این جمله رو احتمالا خیلی شنیدیم... . اما وقتی در شرکتی مشغول به کار هستیم، معمولا قراردادی که داریم صرف دولوپ نیست و نگهداری کد هم جزو کارهای ما محسوب میشه. ما مسئول این هستیم که کد رو به روز نگهداریم و هر زمان که وارد کد میشیم، بهبود بدیم. اما ترس این رو داریم وقتی کد رو تغییر میدیم، بخشی که تغییر داشته به مشکل بخوره و از اون بدتر یه جای دیگه به مشکل بخوره. اما اینها به خودی خود ترس نداره. این ترس زمانی اتفاق میفته که باگی که اتفاق افتاده رو در جریان نیستیم و برنامه زمانی به مشکل میخوره که منتشر شده و دست کاربر هست. خب چکار کنیم که کد رو بدون ترس تغییر بدیم؟ تست بنویسیم! با تست نوشتن، خیلی راحت میتونیم کدهامون رو تغییر بدیم و اگر قسمتی از برنامه دچار مشکل بشه، قبل از اینکه به دست کاربر برسه، خودمون فیکسش کنیم.
وقتی تست کد هارو میخونیم خیلی راحت تر میتونیم کد رو درک کنیم.مثلا خیلی راحت میتونیم ماهیت یک کلاس رو به دست بیاریم و کار هر یک از فانکشن های اون کلاس رو درک کنیم. البته این مرحله یک مقداری هم نیاز به مهارت دولوپر داره تا نام گذاری های مناسبی داشته باشه و به روند آنبرد شدن دولوپر بعدی روی کد کمک کنه.
میتونیم اجرای تست های برنامه رو به فرایند دولوپمون وابسته کنیم تا در زمانی که میخوایم نسخه ای رو منتشر کنیم، تست های برنامه اجرا بشن و در صورتی که اجرای این تست ها به مشکل خورد، از فرایند انتشار جلوگیری کنه. اینطوری اگر تغییراتمون باعث مشکلاتی در قسمت دیگه یا همون قسمت شده باشه رو زودتر متوجه خواهیم شد.
وقتی تست مینویسیم، به طور ناخوداگاه مجبوریم یکسری قوانین رو رعایت کنیم. مثلا برای ماک کردن(اگر در موردش اطلاعی نداری بعدا مفصل در موردش صحبت میکنیم ;) ) نیاز داریم تا تزریق وابستگی رو رعایت کرده باشیم. یا وقتی روی تست نویسیمون تمرکز میکنیم، توابعی مینویسیم که یک مسئولیت دارند و... .
سعی کردم دلایلی رو مطرح کنم که از نظر تجربی بیشتر باهاش آشنا باشیم... . قطعا دلایل بسیار زیادی برای تست نویسی وجود داره، مثلا با نوشتن تست میتونیم کدمون رو روی Api های مختلف تست کنیم و از مشکلات رو گوشی های مختلف جلوگیری کنیم و... .
اینها همگی مقدمه ای بود برای اینکه خیلی زود مقاله دوم رو داشته باشیم در مورد نحوه کد نویسی و اطلاعاتی در مورد پیاده سازی تست نویسی در اندروید.
امیدوارم که تونسته باشم منظورم رو کامل برسونم و مفید باشه. از نظراتتون خیلی استقبال میکنم، ممنون از اینکه تا اینجا اومدید ...
