Ah, aber du hast also von der eigentlichen Erkennung gesprochen? So etwas wie „wenn der Arduino einen bestimmten 433er-Code empfängt, dann wurde die Tür geöffnet“?
Denn das habe ich noch nicht codiert, aber die Features sind vorhanden und bereit zum Codieren 
Also, meiner Meinung nach ist alles gut für eine erste Version. Das Größte, was jetzt noch zu tun bleibt, sind die Tests! Nur ein kleiner Wermutstropfen… Ich habe Schwierigkeiten, die Funktionsweise der Tests zu verstehen 
Könnte eine gute Seele mir bitte helfen, diese Tests richtig zu schreiben?
Vielen Dank
Ja! Das ist nicht codiert? Es wäre vielleicht gut, wenn es vor einer Veröffentlichung funktioniert, sonst ist es wenig nützlich, es zu deployen 
Das Ziel der Tests ist es, den von dir geschriebenen Code auszuführen und das Ergebnis deines Codes zu testen.
Die Tests werden von CircleCI bei jedem Push auf das Gladys-Repo ausgeführt und ermöglichen es, zu überprüfen, dass der neue Code den alten Code nicht „kaputt“ macht.
Zum Beispiel, wenn du eine Funktion schreibst
// lib/sum.js
function sum(a, b) {
return a + b;
}
Möchtest du vielleicht einen Test schreiben, der überprüft, dass sum(1, 2) = 3 ist.
Dein Test könnte so aussehen:
// test/sum.js
const { expect } = require('chai');
const sum = require('../lib/sum.js');
describe('sum', () => {
it('should return 3', () => {
const result = sum(1, 2);
expect(result).to.equal(3);
});
});
Wenn wir diesen Codeausschnitt ausführen, indem wir „mocha“ (das Test-Tool, das wir verwenden) starten, werden wir sehen:
should return 3
Stell dir jetzt vor, dass in naher Zukunft jemand unsere Funktion sum(a, b) kaputt macht und versehentlich das + durch ein * ersetzt.
Bei der Ausführung der Tests würde der Test „should return 3“ 2 zurückgeben, und mocha würde schreien:
should return 3
Expected « 2 » to equal « 3 »
So würden wir wissen, dass dieser PR etwas kaputt macht.
Dieses Beispiel ist simplistisch, aber in der Realität ist es sehr nützlich. Denn du arbeitest jetzt am Arduino, aber was sagt mir das, dass du die Z-Wave-Integration nicht kaputt gemacht hast, während du die Arduino-Integration entwickelt hast? Die Tests 
Das Mocking
Aber jetzt wirst du mir sagen: Ja, aber mein Code ruft über USB einen Arduino auf, wie mache ich das in meinen Tests?
Bei den Tests wollen wir nicht mit der Außenwelt kommunizieren: Es ist sinnlos, das Verhalten der Lib serialport zu testen, die selbst bereits Tests hat!
Wir werden also die Aufrufe an externe Bibliotheken „mocken“, indem wir eine Lib verwenden, die „proxyquire“ heißt ( GitHub - thlorenz/proxyquire: 🔮 Proxies nodejs require in order to allow overriding dependencies during testing. · GitHub )
Oder indem wir die Bibliothek selbst neu schreiben und alle Funktionsaufrufe durch Returns vereinfachen
Beispiel: Im Test des Z-Wave-Service habe ich die Lib openzwave in 28 Zeilen neu geschrieben:
https://github.com/GladysAssistant/Gladys/blob/master/server/test/services/zwave/ZwaveMock.test.js
Jede Funktion der Lib wird durch eine „fake“-Funktion ersetzt, die null zurückgibt.
Ich lade dich ein, die Tests aller anderen Integrationen (server/test/services) zu lesen und dich damit vertraut zu machen
Ein Tutorial könnte dir auch helfen:
Nein, die Bewegungs- und Türsensoren sind noch nicht codiert… Das mache ich heute, das scheint mir relativ einfach umzusetzen ^^
Danke für die Erklärungen, ich glaube, das Problem liegt vor allem beim Mocking. Ich werde versuchen, ein erstes Testskript zu beenden und, wenn du möchtest, poste ich hier den Link, damit du mir sagen kannst, ob meine Vorgehensweise korrekt ist 
Hallo,
Eine erste Version für die Sensoren ist fertig, vielleicht muss man sie später noch verfeinern, aber im Moment scheint mir das Ergebnis gut
Was die Tests angeht, hier sind die Dateien:
@pierre-gilles, wenn du etwas Zeit hast, um die Codes zu überprüfen und mir zu sagen, was noch hinzugefügt/geändert werden sollte, wäre das wirklich super 
Vielen Dank
Edit: Ich arbeite gerade an der demo.json, damit der Service auf der Demo-Website erscheinen kann. Ich denke, dass es bis Mittag fertig sein könnte ^^
Re-edit: Normalerweise ist alles gut.
Anscheinend habe ich nicht die Berechtigung, eine Überprüfung anzufordern, also poste ich die PR hier:
Danke
Danke @billona! Tolle Arbeit! Ich gebe dir nächste Woche zu Beginn ein Feedback
Hallo,
Nach viel Mühe komme ich endlich mit den Tests voran
Ich möchte die lib avrgirl-arduino mocken, um mein Skript setup.js zu überprüfen.
Hier ist, was ich gemacht habe:
Und in setup.test.js habe ich proxyquire verwendet:
Allerdings habe ich das Gefühl, dass meine Tests meinen Mock nicht berücksichtigen:
setup-Methode
2020-06-04T14:16:20+0200 <info> index.js:18 (Server.<anonymous>) Server läuft auf Port 6500
✓ Sollte einen Arduino-Code auf dem Board hochladen (110ms)
2020-06-04T14:16:20+0200 <warn> setup.js:7 () Fehler: Kein Arduino 'mega' gefunden.
at /home/Alexandre/Gladys/server/services/arduino/node_modules/avrgirl-arduino/lib/connection.js:30:25
at /home/Alexandre/Gladys/server/services/arduino/node_modules/avrgirl-arduino/lib/connection.js:70:12
at /home/Alexandre/Gladys/server/services/arduino/node_modules/avrgirl-arduino/lib/connection.js:191:26
at processTicksAndRejections (internal/process/task_queues.js:93:5)
✓ Sollte einen Fehler zurückgeben (451ms)
Danach, um meine Sende- und Empfangsskripte abdecken zu können, muss ich den Teil
if (!this.arduinosPorts[arduinoPath].isOpen) {
this.arduinoParsers[arduinoPath].on('data', async (data) => {
meiner Datei abdecken. Die Logik ist dieselbe für listen und senden.
Aber hier tue ich mich etwas schwer zu sehen, wie ich das abdecken soll…
Kann mir jemand weiterhelfen? Vielen Dank
Mir scheint, dass proxyquire nur auf die Datei funktioniert, die es erfordert. Allerdings sehe ich in deiner Datei /server/services/arduino/lib/index.js kein require für avrgirl-arduino.
Tatsächlich wird avrgirl-arduino nur im Skript /server/services/arduino/lib/setup.js verwendet, daher habe ich kein require in /server/services/arduino/lib/index.js gemacht. Aber ich sehe nicht, wie ich das lösen soll, da setup eine Methode meines ArduinoManagers ist.
Muss ich setup.js separat vom ArduinoManager testen? Serialport und avrgirl-arduino als Eigenschaft des Managers einbinden und sie dann in meinen Skripten verwenden?
Beide Lösungen sind möglich Du entscheidest, welche Lösung dir am einfachsten umzusetzen und in Zukunft zu warten erscheint
Früher haben wir normalerweise alle require-Anweisungen in die index.js des Moduls gestellt und sie als Abhängigkeit in den Manager injiziert. Beispiel: service z-wave
Stimmt, diese Vorgehensweise erscheint mir viel einfacher ^^ Ich habe meine Skripte entsprechend angepasst, und alles scheint zu funktionieren
Jetzt scheint es, als ob meine Codeabdeckung seltsamerweise in der Zwischenzeit abgenommen hat ^^ Ich arbeite daran und gebe dir Bescheid, wenn alles korrekt erscheint
Also, normalerweise bin ich bei Tests nicht so schlecht ^^
Der größte Teil, der mir noch fehlt, betrifft das Lesen und Senden von Daten an die Karte.
Typischerweise sind das Funktionen
port.on('open', function() {});
Zum Beispiel in server/services/arduino/lib/send.js :
Ich finde einfach keine gangbare Lösung, um diesen Teil des Codes abzudecken. Und das ist der größte Teil, der mir noch fehlt ^^
Eine Lösung, um mich zu retten?
Gute Arbeit 
Zwei ergänzende Lösungen:
function onPortOpen () {}
port.on('open', onPortOpen);
port.emit('open');
Was dazu führen wird, die Funktion aufzurufen Achte darauf, auch „port.write“ mit fake.returns(0); zu mocken, zum Beispiel
Ich habe Angst, dass ich einige Dinge nicht verstehe ^^
In meinem SerialPortMock habe ich hinzugefügt
SerialPort.prototype.write = fake.resolves(null);
In Bezug auf
port.emit('open');
Wo rufe ich das auf?
In ArduinoManager.test.js habe ich meinen JSON-Sendetest geändert
it('should send a JSON to the arduino', async () => {
const sendSpy = spy(arduinoManager, 'send');
await arduinoManager.send('/dev/ttyACM0', messageData, 1);
arduinoManager.arduinosPorts['/dev/ttyACM0'].emit('open');
assert.calledOnce(sendSpy);
sendSpy.restore();
});
Aber was dann?
In meinem Fall ist port ein SerialPort-Objekt… Ich sehe nicht wirklich, wie ich diesen Test durchführen soll
Hallo!
Also, hier ist es: Laut dem letzten Codecov-Bericht scheinen meine Tests endlich abgeschlossen zu sein ^^
@pierre-gilles Falls du etwas Fehlendes siehst, warte ich auf dein Feedback, ansonsten ist für mich alles gut für eine erste Version
Ich wollte auch Danke sagen! Da es mein erstes „echtes“ Dev in Node und Preact war, war ich zugegeben an manchen Stellen etwas verloren. Also danke für eure Geduld, und ich freue mich darauf, das Ergebnis mehrerer Dev-Abende als integralen Bestandteil von Gladys 4 zu sehen
Gut, dass du das geschafft hast! Ich schau mir das mal an! Bravo
Für alle, die auf den Arduino-Service warten, ist er jetzt im Testbuild verfügbar!
Zögert nicht, ihn zu testen und Feedback an @billona hier zu geben
Hallo, im letzten Build (Docker-Image) erkennt das Arduino-Modul meine USB-Ports nicht mehr.
Ich weiß, an welchem Port sich das Arduino befindet.
Bus 001 Gerät 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial-Adapter
Bin ich der Einzige, der diesen Fehler hat?
Hallo!!
Ich melde mich nach einer langen Abwesenheit meinerseits wegen der Arbeit wieder ^^’
Ich nehme also die Entwicklung des Arduino-Dienstes wieder auf, mit dem Ziel, ein stabiles und perfektes Ergebnis für den Produktionsstart zu haben
Ich habe meinen lokalen Repository rebase, um mit den neuesten Versionen auf dem neuesten Stand zu sein, ich werde also weiter daran arbeiten und ich werde Rückmeldungen zu meinem Fortschritt geben
)