Apply suggestions from code review

Co-authored-by: Mahdi Hashemi <mahdihashemiii939@gmail.com>

Author: EhsanShahbazii

1-js/03-code-quality/05-testing-mocha/article.md

@@ -74,7 +74,6 @@ describe("pow", function() {
 5. کیس های بیشتری را به spec اضافه می کنیم که احتمالاً هنوز توسط پیاده سازی ها پشتیبانی نشده اند. تست ها به مشکل بر میخورند.
 6. به شماره 3 برگردید و پیاده سازی ها را آپدیت کنید تا وقتی که تست ها خطایی ندهند.
 7. مراحل 3-6 را تکرار کنید تا عملکرد ها آماده شود.
-8. 
 بنابراین، توسعه *تکرار شونده* می باشد. ما spec را می‌نویسیم، آن را پیاده‌سازی می‌کنیم، مطمئن می‌شویم که تست‌ها قبول شدند، سپس تست‌های بیشتری می‌نویسیم، مطمئن می‌شویم که کار می‌کنند و همینطور ادامه می‌دهیم. در نهایت ما یک پیاده سازی موفق و تست هایی برای آن داریم.
 
 بیایید این جریان توسعه را در مثال عملی خود ببینیم.
@@ -336,9 +335,7 @@ describe("pow", function() {
 تست های جدید اضافه شده با شکست مواجه می شوند، زیرا پیاده سازی ما از آنها پشتیبانی نمی کند. BDD اینگونه انجام می شود: ابتدا تست های شکست خورده را می نویسیم و سپس برای آنها پیاده سازی می کنیم.
 
 ```smart header="Other assertions"
-لطفاً به ادعای `assert.isNaN` توجه کنید: `NaN` بودن را بررسی میکند.
-
-There are other assertions in [Chai](https://www.chaijs.com/) as well, for instance:
+لطفاً به `assert.isNaN` توجه کنید: `NaN` بودن را بررسی میکند.
 
 assert دیگری نیز در [chai](https://www.chaijs.com/) وجود دارد، به عنوان مثال:
 
@@ -392,7 +389,6 @@ function pow(x, n) {
 بدون تست, مردم دو راه دارند:
 
 1. برای انجام تغییر که مهم نیست که چه باشد, کاربران ما با اشکال مواجه می شوند، زیرا ما احتمالاً چیزی را به صورت دستی بررسی نمی کنیم.
-
 2. یا، اگر مجازات به وجود آمدن ارور یا خطا سخت باشد، همان طور که تست ها وجود ندارند، مردم از تغییر چنین تابع هایی می ترسند، در نتیجه کد ما قدیمی می شود(زیرا میترسند که کد را توسعه دهند و اروری رخ بدهد) و هیج کس مایل نیست که کد را توسعه دهد و این برای توسعه خوب نیست.
 
 **تست خودکار برای جلوگیری از این مشکلات کمک می کند!**