2016-05-29 3 views
1

Ich habe versucht, Offline-Komponententests für Polymerwebkomponenten zu konfigurieren, die die neueste Version der verteilten Firebase-Datenbank verwenden. Einige meiner Tests sind vorüber, aber andere —, die fast identisch zu passierenden — aussehen, laufen nicht richtig.Komponententest eine Polymerwebkomponente, die Firebase verwendet

Ich habe ein Projekt auf GitHub eingerichtet, das meine Konfiguration zeigt, und ich werde unten einige weitere Kommentare liefern.

Probe: https://github.com/doctor-g/wct-firebase-demo

In diesem Projekt gibt es zwei Suiten von Tests, die gut funktionieren. Die einfachste ist offline-test, die überhaupt keine Web-Komponenten verwendet. Es zeigt einfach, dass es möglich ist, den Offline-Modus der Firebase-Datenbank zu verwenden, um einige Komponententests auszuführen. Das Herzstück dieses Tricks ist das in der unten gezeigten suiteSetup gezeigte Verfahren — einen Trick, den ich von nfarina's work on firebase-server abgeholt habe.

suiteSetup(function() { 
    app = firebase.initializeApp({ 
     apiKey: 'fake', 
     authDomain: 'fake', 
     databaseURL: 'https://fakeserver.firebaseio.com', 
     storageBucket: 'fake' 
    }); 
    db = app.database(); 

    db.goOffline(); 
}); 

Alle Tests in offline-test Pass.

Die nächste Suite ist wct-firebase-demo-app_test.html, die die gleichnamige Webkomponente testen. Diese Suite enthält eine Reihe von Komponententests, die wie folgt konfiguriert sind: offline-test. Nach der Idee der Abhängigkeitsinjektion verfügt die Komponente wct-firebase-demo-app über ein database-Attribut, in das die Firebase-Datenbankreferenz übergeben wird. Dies wird verwendet, um alle Firebase-Aufrufe durchzuführen. Hier ist ein Beispiel aus der Suite:

test('offline set string from web component attribute', function(done) { 
    element.database = db; 
    element.database.ref('foo').set('bar'); 
    element.database.ref('foo').once('value', function(snapshot) { 
     assert.equal(snapshot.val(), 'bar'); 
     done(); 
    }); 
    }); 

ich einige sehr einfache Methoden in der Komponente als auch, in meinem Versuch, in Richtung auf den Scherben triangulieren ich in einem Moment reden würde. Es genügt zu sagen, dass dieser Test bestanden:

test('offline push string from web component function', function(done) { 
    element.database = db; 
    let resultRef = element.pushIt('foo', 'bar'); 
    element.database.ref('foo').once('value', function(snapshot) { 
     assert.equal(snapshot.val()[resultRef.key], 'bar'); 
     done(); 
    }); 
    }); 

und wird von dieser Implementierung unterstützt in wct-firebase-demo-app:

pushIt: function(at, value) { 
    return this.database.ref(at).push(value); 
    }, 

Wieder einmal alle diese weiter. Jetzt kommen wir zum echten Dilemma. Es gibt eine Reihe von Tests für ein anderes Element, x-element, das ein Verfahren pushData hat:

pushData: function(at, data) { 
    this.database.ref(at).push(data); 
    } 

Der Test für diese Methode ist der einzige Test in its suite:

test('pushData has an effect', function(done) { 
    element.database = db; 
    element.pushData('foo', 'xyz'); 
    db.ref('foo').once('value', function(snapshot) { 
     expect(snapshot.val()).not.to.be.empty; 
     done(); 
    }); 
    }); 

Dieser Test nicht besteht. Während dieses Test ausgeführt wird, die Konsole mit einer Fehlermeldung kommt:

Your API key is invalid, please check you have copied it correctly. 

Durch einige Haltepunkte setzen und durch die Ausführung gehen, so scheint es mir, dass dieser Fehler zu once nach dem Anruf kommt aber vor dem Rückruf wird ausgelöst. Beachten Sie, dass dies nicht mit der gleichen Teststruktur geschieht, die oben in wct-firebase-demo-app beschrieben ist.

Das ist, wo ich stecke. Warum funktionieren offline-test und wct-firebase-demo-app_test Suites gut, aber ich bekomme diesen API-Schlüssel Fehler in x-element_test? Der einzige andere Hinweis, den ich habe, ist, dass, wenn ich einen gültigen API-Schlüssel in meine initializeApp Konfiguration kopiere, dann bekomme ich stattdessen einen Test-Timeout.

UPDATE:

Hier ist ein (gepatcht-together) Bild meines Konsolenprotokolls, wenn die Tests laufen .:

Console log showing the failing test

die Ausgabe von tony19 unten gebracht zu veranschaulichen, ist hier die Konsolenprotokoll mit nur pushData has an effect in x-element_test kommentiert out:

Console log showing passing tests

+0

Ah, sehr nützliche Beobachtung @ tony19! Ich hatte der Ausgabe des WT vertraut, ohne auf die Konsolenprotokolle zu schauen. Vielleicht ist es mehr ein Kartenhaus als ich erwartet hatte. – Paul

Antwort

0

Die offline-test Ergebnisse sind offensichtlich falsch positive. Wenn Sie die Chrome-Konsole überprüfen, wirft offline-test tatsächlich den gleichen Fehler:

enter image description here

Der Fehler hat keinen Einfluss auf die Testergebnisse sehr wahrscheinlich, weil die API-Schlüssel Validierung erfolgt asynchron nach dem Test bereits abgeschlossen hat. Wenn Sie in diese Validierung eingreifen könnten, könnten Sie den Fehler in Ihren Tests abfangen.

Das Auskommentieren aller Tests mit Ausnahme von offline firebase is ok zeigt den noch immer auftretenden Fehler, der auf suiteSetup() zeigt. Wenn Sie das Problem weiter einschränken, indem Sie 2 der 3 Funktionsaufrufe im Setup kommentieren, sehen wir, dass der Fehler durch den Aufruf an firebase.initializeApp() verursacht wird (und nicht unbedingt mit once() in Verbindung steht, wie Sie vermutet hatten).

Eine Umgehungslösung, die Sie in Betracht ziehen sollten, besteht darin, die Firebase-Bibliothek in einer Klasse/Schnittstelle zu verpacken und diese für Unit-Tests zu verspotten.

+0

Das ist nicht das gleiche Verhalten, das ich hier sehe: Wenn ich alle Tests außer "offline Firebase ist ok" kommentieren, dann funktioniert alles gut, ohne einen API-Fehler zu werfen. Wenn ich in 'x-element_test' nur" pushData hat einen Effekt "auskommentiert, wird die gesamte Suite ausgeführt, ohne dass Warnungen oder Fehler in der Konsole generiert werden. – Paul

+0

Ich bin gespannt, wie sich Änderungen in x-element_test.html auf offline-test.html auswirken würden. Das Verhalten, das ich sehe, ist für mich auf OSX El Capitan, Chrome 51, bei commit ['e5d1d55'] (https://github.com/doctor-g/wct-firebase-demo/commit/e5d1d557eb25351d728835f3bca2a0dfbaddc315) leicht reproduzierbar. – tony19

+0

Um dies zu verdeutlichen, starte ich 'offline-test' indem ich' offline-test.html' öffne. Ich gehe davon aus, dass du es basierend auf deinen Screenshots anders ausführst. Siehst du einen Unterschied, wenn du diese Datei alleine öffnest? – tony19

Verwandte Themen