smalljs$molSuche⌘ KDokuPlaygroundVergleichÖkosystemÜberDE
TestenGetting StartedEinführungMentales ModellErste SchritteVon TypeScript zu view.treeProjektstrukturWerkzeugeEssentialsInstallationViewsZustand und ReaktivitätRoutingRenderingTestenDeploymentFehlerbehebungDataDatenabrufDatenschemasGiper BazaMoreSchaufensterVon React, Vue und SvelteKochbuchAdvancedPluginsModul-MetadatenOfflineGhost-AnsichtenAboutFAQTeamReleasesAPI$mol_button_major$mol_button_minor$mol_string$mol_number$mol_text$mol_paragraph$mol_list$mol_row$mol_link$mol_check$mol_switch$mol_select$mol_scroll$mol_page$mol_pick

Testen

Eine $mol-View ist eine Funktion ihres Zustands, und das ändert, wie ein Test aussieht. Ein Benutzerszenario wird als Aufrufe der eigenen Methoden der View geschrieben: den Entwurf setzen, die Aktion ausführen, lesen, was der Benutzer sehen würde.1app.draft( 'Milk' )2app.add()3$mol_assert_equal( app.item_title( 0 ), 'Milk' )Keine Selektoren, kein Browser, kein Playwright oder Cypress, kein Warten auf irgendetwas. Dieselbe Datei bringt Ihnen außerdem:Tempo. Tests laufen in Node in Millisekunden; tausend davon brauchen etwa eine Minute. node my/hello/-/node.test.js führt die eines Moduls aus.Keine Einrichtung. Eine hello.test.ts neben der Komponente wird vom Builder aufgesammelt und in -/node.test.js kompiliert. Die kontinuierliche Integration mit mam_build führt sie aus und lässt den Build scheitern, wenn ein Test fehlschlägt.Dienste über den Kontext austauschen. Jeder Test bekommt sein eigenes $, und alles, was eine Komponente über this.$.X erreicht, wird ausgetauscht, indem man diesem $ ein Test-Double zuweist. Das ist der Grund, this.$.$mol_fetch statt $mol_fetch zu schreiben: Das erste ist ersetzbar, das zweite nicht.Gemockte Zeit. Über den Kontext erzeugte Timer ticken nicht von selbst; $mol_after_mock_warp() führt aus, was in der Warteschlange steht.Ein echtes DOM, wenn Sie eines brauchen. Das Node-Bundle trägt jsdom mit sich, also funktionieren dom_node() und querySelectorAll in derselben Testdatei.

Ein Szenario über View-Methoden

Nehmen Sie die Todo-Liste aus dem Kochbuch: eine Zeichenkette draft?, eine Liste items, eine Aktion add und eine Aktion delete. Ihr Test liegt in my/todo/todo.test.ts:1namespace $ {2 $mol_test({3 4 'add an item and delete it'( $ ) {5 const app = $my_todo.make({ $ })6 7 app.draft( 'Milk' )8 app.add()9 $mol_assert_equal( app.items().length, 1 )10 $mol_assert_equal( app.item_title( 0 ), 'Milk' )11 $mol_assert_equal( app.draft(), '' )12 13 app.delete( 0 )14 $mol_assert_like( app.item_rows(), [] )15 },16 17 'blank draft adds nothing'( $ ) {18 const app = $my_todo.make({ $ })19 20 app.draft( ' ' )21 app.add()22 $mol_assert_like( app.items(), [] )23 },24 25 })26}Diese Seite auf GitHub bearbeitenWar das hilfreich?JaNeinZurückRenderingWeiterDeploymentAuf dieser SeiteEin Szenario über View-MethodenEinen Dienst mockenZeitÜber das DOMWas ein Node-Test nicht abdecktPraktische HinweiseWeiter
Type to search the documentation.