نمای $mol تابعی از وضعیتِ خودش است، و همین تغییر میدهد که یک تست چه شکلی دارد. سناریوی کاربر بهصورتِ فراخوانیِ متدهای خودِ نما نوشته میشود: پیشنویس را بگذارید، کنش را اجرا کنید، آنچه را کاربر میدید بخوانید.1app.draft('Milk')2app.add()3$mol_assert_equal(app.item_title(0),'Milk')نه سلکتوری، نه مرورگری، نه Playwright و Cypressی، نه انتظاری برای هیچچیز. همان فایل اینها را هم به شما میدهد:سرعت. تستها در Node در چند میلیثانیه اجرا میشوند؛ هزارتاشان حدود یک دقیقه وقت میبرد. nodemy/hello/-/node.test.js تستهای یک ماژول را اجرا میکند.بدونِ هیچ راهاندازی. یک hello.test.ts کنارِ کامپوننت را سازنده برمیدارد و در -/node.test.js کامپایل میکند. یکپارچهسازیِ مداوم با mam_build اجرایش میکند و وقتی تستی بیفتد ساخت را میشکند.جایگزینیِ سرویسها از راهِ زمینه. هر تست $ِ خودش را میگیرد، و هرچه کامپوننت از راهِ this.$.X به آن میرسد با انتسابِ یک بدلِ تستی به همان $ عوض میشود. دلیلِ نوشتنِ this.$.$mol_fetch بهجای $mol_fetch همین است: اولی جایگزینشدنی است، دومی نه.زمانِ ماکشده. تایمرهایی که از راهِ زمینه ساخته شوند خودبهخود تیک نمیزنند؛ $mol_after_mock_warp() هرچه در صف است را اجرا میکند.یک DOMِ واقعی هر وقت لازمش داشتید. باندلِ Node جیاسدام را همراه دارد، پس dom_node() و querySelectorAll در همان فایلِ تست کار میکنند.
فهرستِ کارها را از کتابِ آشپزی بردارید: یک رشتهٔ draft?، یک فهرستِ items، یک کنشِ add و یک کنشِ delete. تستش در my/todo/todo.test.ts مینشیند:1namespace ${2$mol_test({34'add an item and delete it'($){5const app=$my_todo.make({$})67app.draft('Milk')8app.add()9$mol_assert_equal(app.items().length,1)10$mol_assert_equal(app.item_title(0),'Milk')11$mol_assert_equal(app.draft(),'')1213app.delete(0)14$mol_assert_like(app.item_rows(),[])15},1617'blank draft adds nothing'($){18const app=$my_todo.make({$})1920app.draft(' ')21app.add()22$mol_assert_like(app.items(),[])23},2425})26}ویرایش این صفحه در GitHubآیا این مفید بود؟بلهخیرقبلیرندربعدیاستقراردر این صفحهیک سناریو از راهِ متدهای نماماککردنِ یک سرویسزماناز راهِ DOMآنچه تستِ Node پوشش نمیدهدنکتههای عملیبعدیType to search the documentation.
